From: Noah Misch <noah@leadboat.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: vignesh21@gmail.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: sequencesync worker race with REFRESH SEQUENCES
Date: Sat, 11 Jul 2026 13:14:10 -0700
Message-ID: <20260711201410.4a.noahmisch@microsoft.com> (raw)
In-Reply-To: <CAA4eK1KFgVFdocPt4TPXmkkOfwY7YNRfG-0jRVKCuOaMNWSCUA@mail.gmail.com>
References: <20260710045217.f0.noahmisch@microsoft.com>
<CAA4eK1KFgVFdocPt4TPXmkkOfwY7YNRfG-0jRVKCuOaMNWSCUA@mail.gmail.com>
On Sat, Jul 11, 2026 at 10:31:06AM +0530, Amit Kapila wrote:
> On Fri, Jul 10, 2026 at 10:22 AM Noah Misch <noah@leadboat.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.
I haven't formed a preference, but I would use these principles to decide.
Assume we eventually support continuous, WAL-decoded replication of sequences,
not just snapshot replication. Which choice would make sequence replication
behave most like table replication under the analogous concurrent actions?
If it's an ERROR, I'd probably omit the doc note, since the ERROR would be
clear and unsurprising. In general, there's no need to document everything
that causes an error. Documentation is most useful when an error is
surprising or affects how the user writes the application.
If the command merely raises a WARNING, documentation becomes more important,
because warnings are easy to overlook. That is also an argument against a
WARNING: if the user must take action to avoid incorrect replicated state, it
is risky to rely on the user noticing one.
Does that help?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, amit.kapila16@gmail.com, vignesh21@gmail.com
Subject: Re: sequencesync worker race with REFRESH SEQUENCES
In-Reply-To: <20260711201410.4a.noahmisch@microsoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox