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

Move extension tests to their own file #6954

Merged
merged 7 commits into from
Mar 1, 2024
Merged

Conversation

msullivan
Copy link
Member

They are slow and large and I usually don't actually care to run them
when running ddl tests.

They are slow and large and I usually don't actually care to run them
when running ddl tests.
@msullivan msullivan force-pushed the test-extensions-alone branch from 3932e82 to ce7feed Compare March 1, 2024 06:32
@msullivan
Copy link
Member Author

I observed flakes here earlier, but they went away. I'm going to merge this now, then send up a clean PR to address that flake and another, since it involves some infrastructure

@msullivan msullivan merged commit 37cfbe7 into master Mar 1, 2024
23 checks passed
@msullivan msullivan deleted the test-extensions-alone branch March 1, 2024 20:01
msullivan added a commit that referenced this pull request Mar 1, 2024
In general we should be using retrying transactions. Our isolated
tests do retries at the outside, but non-isolated ones don't
necessarily.

Implement _run_and_rollback_retrying and use it some places that
TransactionSerializationError flakes have been seen (in #6954 and
in nightly CI).

Honestly I don't really think that these places ought to be having
TransactionSerializationErrors, but also it really is pretty required
to do retries when using SERIALIZABLE, so we should start moving
towards being more consistent about it.
msullivan added a commit that referenced this pull request Mar 2, 2024
In general we should be using retrying transactions. Our isolated
tests do retries at the outside, but non-isolated ones don't
necessarily.

Implement _run_and_rollback_retrying and use it some places that
TransactionSerializationError flakes have been seen (in #6954 and
in nightly CI).

Honestly I don't really think that these places ought to be having
TransactionSerializationErrors, but also it really is pretty required
to do retries when using SERIALIZABLE, so we should start moving
towards being more consistent about it.
msullivan added a commit that referenced this pull request Mar 7, 2024
They are slow and large and I usually don't actually care to run them
when running ddl tests.
msullivan added a commit that referenced this pull request Mar 7, 2024
In general we should be using retrying transactions. Our isolated
tests do retries at the outside, but non-isolated ones don't
necessarily.

Implement _run_and_rollback_retrying and use it some places that
TransactionSerializationError flakes have been seen (in #6954 and
in nightly CI).

Honestly I don't really think that these places ought to be having
TransactionSerializationErrors, but also it really is pretty required
to do retries when using SERIALIZABLE, so we should start moving
towards being more consistent about it.
msullivan added a commit that referenced this pull request Mar 7, 2024
They are slow and large and I usually don't actually care to run them
when running ddl tests.
msullivan added a commit that referenced this pull request Mar 7, 2024
In general we should be using retrying transactions. Our isolated
tests do retries at the outside, but non-isolated ones don't
necessarily.

Implement _run_and_rollback_retrying and use it some places that
TransactionSerializationError flakes have been seen (in #6954 and
in nightly CI).

Honestly I don't really think that these places ought to be having
TransactionSerializationErrors, but also it really is pretty required
to do retries when using SERIALIZABLE, so we should start moving
towards being more consistent about it.
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

Successfully merging this pull request may close these issues.

3 participants