Re: sequencesync worker race with REFRESH SEQUENCES - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: sequencesync worker race with REFRESH SEQUENCES
Date
Msg-id CAA4eK1K8Sf0sN9NYPeOLOejrqPWy9pS8Wx3+xNqo05FJi4CLxw@mail.gmail.com
Whole thread
In response to Re: sequencesync worker race with REFRESH SEQUENCES  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Wed, Jul 29, 2026 at 8:35 AM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.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.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Missing list_free in publicationcmds.c:OpenTableList
Next
From: Michael Banck
Date:
Subject: Re: Add statistics refresh materialized view