Re: sequencesync worker race with REFRESH SEQUENCES

On Wed, Jul 29, 2026 at 4:35 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Jul 29, 2026 at 8:35 AM Hayato Kuroda (Fujitsu)
> <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> >
> > > Yes, that is correct. How about a comment as follows:
> > > /*
> > > * Lock the sequence so its identity (namespace and name) cannot change
> > > * under us via a concurrent DROP, RENAME or SET SCHEMA while we read it.
> > > * The lock is released immediately rather than at transaction end. The
> > > * later synchronization does not depend on this captured identity
> > > * remaining valid, as it re-opens the sequence and tolerates concurrent
> > > * changes. Releasing early also avoids holding one lock per sequence,
> > > * which could exhaust the lock table.
> > > */
> >
> > LGTM.
> >
>
> Thanks, pushed now.
>

FYI, somehow the "rather than" wording of the above comment became a
"rathen then" typo in the master code [1].

======
[1] https://github.com/postgres/postgres/commit/c12c101b0846b1e6488f2dc986a852fbc6bf2e3b#diff-e188109d851e85cc74d6bb7543f8ddf2be5cc2764e976ed44a7c82ddcc5ad884R758

Kind Regards,
Peter Smith.
Fujitsu Australia