Re: sequencesync worker race with REFRESH SEQUENCES

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: sequencesync worker race with REFRESH SEQUENCES
Date: 2026-07-11 07:15:58
Message-ID: CALDaNm3ROpNN_MPnejzMNb7aVj9=LAehvyuQS+WRH4cwMO6hoA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 11 Jul 2026 at 10:31, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Jul 10, 2026 at 10:22 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> >
> > A Fable 5 review of logical replication of sequences found a way to get
> > subscribed sequences into READY state despite the subscriber side having data
> > older than the last REFRESH SEQUENCES. I'm attaching the test case it wrote.
> > I reviewed the test, and I think it identifies a genuine defect.
> >
>
> Good catch. We have following ways to fix: (a) As mentioned by
> Kuroda-san, during REFRESH SEQUENCES command, if we detect that the
> sequencesync worker is in progress, we can either make the command
> wait till the sequencesync is finished, return ERROR suggesting
> sequence sync already in-progress, or first stop the sequencesync
> worker and then complete the command and let the worker restart after
> REFRESH command is finished; (b) raise a WARNING+HINT for sequences
> that are not in ready state as proposed by Vignesh. Shall we
> additionally add a Note for user to ensure seuencesync worker is not
> in-progress before REFRESH SEQUENCES command?
>
> Do you have any preference? I think WARNING+HINT should be sufficient
> for users as this shouldn't be a common scenario but going the other
> way is also fine.

Both approaches seem reasonable to me. One downside of the WARNING
approach is that if a subscription contains many sequences and the
user immediately reruns ALTER SUBSCRIPTION ... REFRESH SEQUENCES, they
could receive a large number of warnings one for each sequence that is
already being synchronized which may be noisy and not particularly
useful.

Here is a patch implementing approach (a), which detects whether a
sequence synchronization worker is already running for the
subscription. If a synchronization is already in progress, ALTER
SUBSCRIPTION ... REFRESH SEQUENCES reports an error and asks the user
to rerun the command after the current synchronization completes.

Regards,
Vignesh

Attachment Content-Type Size
0001-Reject-concurrent-sequence-refreshes.patch application/octet-stream 3.1 KB
0002-Add-a-test-for-concurrent-REFRESH-SEQUENCES.patch application/octet-stream 7.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2026-07-11 07:26:56 Re: use of SPI by postgresImportForeignStatistics
Previous Message Etsuro Fujita 2026-07-11 06:04:56 Re: use of SPI by postgresImportForeignStatistics