Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sequences catchup regression tests #40

Open
lemrouch opened this issue Nov 2, 2022 · 5 comments
Open

Sequences catchup regression tests #40

lemrouch opened this issue Nov 2, 2022 · 5 comments

Comments

@lemrouch
Copy link
Contributor

lemrouch commented Nov 2, 2022

Hi,
I'm trying to write tests as you have asked me to.
So far I was able to figure out the database needs

datestyle = 'Postgres, MDY'
intervalstyle = 'postgres_verbose'

but I'm still unable to get exactly the same output as in check_results.out.
I have no idea what is check_results_1.out good for.

I guess you want me just to add SELECT testschema1.seq1.NEXTVAL FROM dual; to migrate.sql, SELECT nextval('testschema1.seq1'); to check_results.sql and add relevant output to check_results.out. Right?
BTW: This might hinder subsequent runs of the check.

laurenz added a commit that referenced this issue Nov 3, 2022
This addresses some of the questions in #40.
@laurenz
Copy link
Collaborator

laurenz commented Nov 3, 2022

Before I try to answer, let me express my thanks for all your work and improvements on this project. I really appreciate it!

datestyle and intervalstyle are set by the regression test machinery when you run the regression tests. I realize that I did not document that, so I have added some documentation in 4f09cf8.

If you get any different results, that could be an artifact of my PostgreSQL configuration. Share your results, and hopefully I can fix the regression tests. check_results_1.out is an "alternate result file". Git tells me that I added that in 75c89fa because \d changed its output in v11. I guess the old result file is obsolete by now and could be removed (and the new one renamed).

My idea how sequences could be tested is that you add one or two NEXTVAL calls (using oracle_execute) to migrate.sql in the section /* add some test data for replication */ and check the value of the local sequence after /* clean up replication tools */. You should reset the Oracle sequence in /* clean up Oracle test data */ so that the next regression test finds it in the original state.

@lemrouch
Copy link
Contributor Author

lemrouch commented Nov 3, 2022

add one or two NEXTVAL

was my original idea as well but it's way too optimistic.
We have to deal with sequence created with CACHE 10 and we are catching up it's high watermark, not the real last value.
We would have to cross the cache size to see any change in PG sequence.

@laurenz
Copy link
Collaborator

laurenz commented Nov 3, 2022

Oh, I'd keep it simple. I added to CACHE 10 only to see if the property was migrated. You can simply create another sequence with CACHE 1 and use that for your test.

@lemrouch
Copy link
Contributor Author

You can simply create another sequence with CACHE 1 and use that for your test.

Fun fact is that you can't: ORA-04010: the number of values to CACHE must be greater than 1

laurenz added a commit that referenced this issue Nov 14, 2022
This addresses some of the questions in #40.
@laurenz
Copy link
Collaborator

laurenz commented Nov 14, 2022

Then omit the CACHE clause altogether.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants