Horton

Re: [HACKERS] Concurrent ALTER SEQUENCE RESTART Regression

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Michael Paquier <michael.paquier@gmail.com>, Noah Misch <noah@leadboat.com>, Jason Petersen <jason@citusdata.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-05-24T14:24:19Z
Lists: pgsql-bugs, pgsql-hackers 
On Wed, May 24, 2017 at 9:04 AM, Andres Freund <andres@anarazel.de> wrote:
> At the very least we'll have to error out. That's still not nice usability wise, but it sure beats returning flat out wrong values.

I'm not sure.  That seems like it might often be worse.  Now you need
manual intervention before anything even has a hope of working.

> I suspect that the proper fix would be to use a different relfilenode after ddl, when changing the seq file itself (I.e. setval and restart).  That seems like it'd be architecturally more appropriate, but also some work.

I can see some advantages to that, but it seems far too late to think
about doing that in v10.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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