Re: BUG #19687: ALTER SEQUENCE provokes error XX001 could not read blocks

Hi,

On Thu, 24 Sept 2026 at 06:50, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Sep 24, 2026 at 01:09:12AM +0530, Ayush Tiwari wrote:
> > I don't have much background on the lock levels needed here, but taking
> > AccessExclusiveLock upfront seems reasonable given the storage replacement.
> > I'm less sure whether it's too strong for cases like OWNED BY.
> > [I've sent a diff upthread, can add a patch if that's the right way to go]
> >
> > Cc'ing Andres, Michael and Peter, who were involved in the original
> > sequence locking and transactional changes. Does this approach make
> > sense, or am I missing something here?
>
> Where do you mean to add this extra level of locking?

I meant the initial RangeVarGetRelidExtended() call in AlterSequence(),
before init_sequence(), replacing the existing lock mode.

My thinking was that, since ALTER can replace the sequence's storage,
we'd want to exclude ordinary scans until the transaction finishes too.
Taking AccessExclusiveLock at the initial lookup seemed consistent
with that, much like the locking required by ResetSequence()?

diff --git a/src/backend/commands/sequence.c b/src/backend/commands/sequence.c
--- a/src/backend/commands/sequence.c
+++ b/src/backend/commands/sequence.c
@@ -447,7 +447,7 @@ AlterSequence(ParseState *pstate, AlterSeqStmt *stmt)

/* Open and lock sequence, and check for ownership along the way. */
relid = RangeVarGetRelidExtended(stmt->sequence,
- ShareRowExclusiveLock,
+ AccessExclusiveLock,
stmt->missing_ok ? RVR_MISSING_OK : 0,
RangeVarCallbackOwnsRelation,
NULL);

Regards,
Ayush