Re: sequencesync worker race with REFRESH SEQUENCES

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: vignesh21(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: sequencesync worker race with REFRESH SEQUENCES
Date: 2026-07-11 05:01:06
Message-ID: CAA4eK1KFgVFdocPt4TPXmkkOfwY7YNRfG-0jRVKCuOaMNWSCUA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2026-07-11 05:52:26 Re: Row pattern recognition
Previous Message Bertrand Drouvot 2026-07-11 04:16:13 Re: relfilenode statistics