I'm still looking into this, but here are some preliminary thoughts. On Mon, Dec 29, 2025 at 12:26:01PM -0500, Tom Lane wrote: > In the no-good-deed-goes-unpunished department: pg_dump's use > of pg_get_sequence_data() (nee pg_sequence_read_tuple()) is > evidently responsible for the complaint in bug #19365 [1] > that pg_dump can no longer survive concurrent sequence drops.
This seems to be reproducible on older versions. With a well-timed sleep right before dumpSequenceData()'s pre-v18 query, I can produce a relation-does-not-exist error with a concurrent sequence drop. Perhaps v18 made this easier to reach, but given it moved the sequence tuple access to collectSequences()'s query, I'm not sure why that would be. > BTW, I'm unconvinced that pg_dump behaves sanely when this function > does return nulls. I think the ideal thing would be for it to skip > issuing setval(), but right now it looks like it will issue one with > garbage values. Before v18, pg_dump just ERRORs due to insufficient privileges on a sequence. IMHO that makes sense. If you ask pg_dump to dump something you don't have privileges on, I'd expect it to error instead of silently skipping it. -- nathan
