Re: sequencesync worker race with REFRESH SEQUENCES

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: sequencesync worker race with REFRESH SEQUENCES
Date: 2026-07-17 06:44:19
Message-ID: CAA4eK1+2ErJXCyMRJ0W_6a=Lpw=MZV2qC=nKDsotDoKeq6XNvw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 17, 2026 at 11:03 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Could we, on detecting the race condition problem, wait awhile
> to see if it resolves?
>

Yes, we can do that. But it may not be completely reliable because
sequencesync worker can exit and restart due to some ERROR. In those
cases, again we can miss synchronizing the latest value of sequence.

>
> Or simply exit and let the REFRESH be
> a no-op?
>

But this will bring us to where we are without commit f38afa4ab. We
wanted to make users aware that REFRESH may not have refreshed all
sequences, so do you think a LOG/WARNING with a hint be better option
or we can always points user to our documentation [1] (Refreshing
Out-of-Sync Sequences) where we documented how ensure sequences are
synced?

[1] - https://www.postgresql.org/docs/19/logical-replication-sequences.html#LOGICAL-REPLICATION-SEQUENCES

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ian Lawrence Barwick 2026-07-17 06:44:50 [PATCH] Rename "getdatabaseencoding()" to "pg_database_encoding()", and document
Previous Message Rafia Sabih 2026-07-17 06:38:35 Re: Available disk space per tablespace