Re: Race between pg_dump and ALTER SEQUENCE can cause read failure

On Wed, Jul 29, 2026 at 05:48:46PM +0530, Amit Kapila wrote:
> On Tue, Jul 28, 2026 at 8:45 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>> I'm of two minds about this. I think this has been a problem for much
>> longer, just with different symptoms. Even today, a SELECT run
>> concurrently with ALTER on a sequence might return 0 rows, which caused
>> pg_dump to error before it used pg_get_sequence_data(). On the other hand,
>> scary errors are no good, and the deadlock risk of bumping
>> pg_get_sequence_data() to RowExclusiveLock might be minimal.
>>
>> I'm tempted to suggest that living with the bug is the better option here,
>> especially considering the apparent lack of field reports.
>
> The lack of field reports could be because the relevant
> pg_get_sequence_data() path is new and the window to get this issue is
> narrow.

Well, my point is that I don't think this failure mode is actually new at
all. pg_get_sequence_data() just changes where it happens.

> Though I agree that this can occur rarely, the proposed fix
> seems like a cheap insurance against such a rare but nasty occurrence.

I'm okay with bumping up the lock mode in pg_get_sequence_data() if folks
agree it is worth the risk. I don't have any concrete concerns at the
moment, but I'll plan on taking a closer look soon.

> Isn't it better to bump the mode in pg_get_sequence_data()? I think
> adding a comment for the non-obvious choice of lock in
> pg_get_sequence_data() sounds reasonable to me as proposed by Vignesh.

I certainly think Vignesh's proposal is better from a deadlock standpoint,
but this leaves the race between SELECT and ALTER intact.

--
nathan