Date: Sat, 11 Jul 2026 13:14:10 -0700
From: Noah Misch <noah@leadboat.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: vignesh21@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: sequencesync worker race with REFRESH SEQUENCES
Message-ID: <20260711201410.4a.noahmisch@microsoft.com>
References: <20260710045217.f0.noahmisch@microsoft.com>
 <CAA4eK1KFgVFdocPt4TPXmkkOfwY7YNRfG-0jRVKCuOaMNWSCUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAA4eK1KFgVFdocPt4TPXmkkOfwY7YNRfG-0jRVKCuOaMNWSCUA@mail.gmail.com>
User-Agent: Mutt/2.3.0 (2026-01-25)
Archived-At: 
 <https://www.postgresql.org/message-id/20260711201410.4a.noahmisch%40microsoft.com>
Precedence: bulk

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?