Horton

Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Petr Jelinek <petr.jelinek@2ndquadrant.com>, pgsql-hackers@postgresql.org, Noah Misch <noah@leadboat.com>, Jason Petersen <jason@citusdata.com>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-05-11T20:34:33Z
Lists: pgsql-bugs, pgsql-hackers 
On 2017-05-11 11:35:22 -0400, Peter Eisentraut wrote:
> On 5/10/17 12:24, Andres Freund wrote:
> > The issue isn't the strength, but that we currently have this weird
> > hackery around open_share_lock():
> > /*
> >  * Open the sequence and acquire AccessShareLock if needed
> >  *
> >  * If we haven't touched the sequence already in this transaction,
> >  * we need to acquire AccessShareLock.  We arrange for the lock to
> >  * be owned by the top transaction, so that we don't need to do it
> >  * more than once per xact.
> >  */
> > 
> > This'd probably need to be removed, as we'd otherwise would get very
> > weird semantics around aborted subxacts.
> 
> Can you explain in more detail what you mean by this?

Well, right now we don't do proper lock-tracking for sequences, always
assigning them to the toplevel transaction.  But that doesn't seem
proper when nextval() would conflict with ALTER SEQUENCE et al, because
then locks would continue to be held by aborted savepoints.

- Andres

Commits

  1. Make ALTER SEQUENCE, including RESTART, fully transactional.

  2. Modify sequence catalog tuple before invoking post alter hook.

  3. Use weaker locks when updating pg_subscription_rel

  4. Add pg_sequence system catalog

  5. Modify sequence state storage to eliminate dangling-pointer problem