Re: sequencesync worker race with REFRESH SEQUENCES - Mailing list pgsql-hackers

From Tom Lane
Subject Re: sequencesync worker race with REFRESH SEQUENCES
Date
Msg-id 3848535.1784266437@sss.pgh.pa.us
Whole thread
In response to Re: sequencesync worker race with REFRESH SEQUENCES  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
[ please, please, please: proper bottom-quoting does not mean to quote
the entire damn thread and then add a few lines of new material.  The
point of quoting is just to *briefly* remind readers of the topic. ]

vignesh C <vignesh21@gmail.com> writes:
> While reviewing this further, I noticed another scenario. After the
> sequence synchronization worker marks all sequences as READY, if we
> pause execution at report_sequence_errors(), an ALTER SUBSCRIPTION ...
> REFRESH SEQUENCES can still fail. This means that checking
> pg_subscription_rel and verifying that all sequences are in the READY
> state is not sufficient. We also need to ensure that the sequence
> synchronization worker itself has exited before proceeding, since it
> may still be running even after updating the state to READY. I've
> updated the test accordingly to include this additional check.

I grow even more skeptical that f38afa4ab was a good idea.  It seems
inevitable that it will cause annoying failures in the field.
I think that our goal here needs to be to fix the backend, not
band-aid these existing, always-worked-before test cases.

Could we, on detecting the race condition problem, wait awhile
to see if it resolves?  Or simply exit and let the REFRESH be
a no-op?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Tags in the commitfest app: How to use them and what tags to add?
Next
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH] Rename "getdatabaseencoding()" to "pg_database_encoding()", and document