Horton

Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>, Jason Petersen <jason@citusdata.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-05-24T03:25:17Z
Lists: pgsql-bugs, pgsql-hackers 
On 2017-05-23 22:47:07 -0400, Robert Haas wrote:
> On Mon, May 22, 2017 at 11:42 AM, Andres Freund <andres@anarazel.de> wrote:
> > Ooops.
> >
> > Two issues: Firstly, we get a value smaller than seqmin, obviously
> > that's not ok. But even if we'd error out, it'd imo still not be ok,
> > because we have a command that behaves partially transactionally
> > (keeping the seqmax/min transactionally), partially not (keeping the
> > current sequence state at -9).
> 
> I don't really agree that this is broken.

Just a quick clarification question: You did notice that nextval() in S1
after the rollback returned -9, despite seqmin being 0?  I can see
erroring out being acceptable, but returning flat out wrong values....?

- 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