Horton

Re: Concurrent ALTER SEQUENCE RESTART Regression

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>, Andres Freund <andres@anarazel.de>
Cc: Jason Petersen <jason@citusdata.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-04-27T01:07:20Z
Lists: pgsql-bugs, pgsql-hackers 
On 4/26/17 19:12, Michael Paquier wrote:
> Well, there are more DDL commands where it is possible to see "tuple
> concurrently updated" easily, an example is ALTER ROLE. So nothing is
> concurrent-proof with this code and I think needs a careful lookup
> because this error should never be something that is user-visible.

Yeah, it's been like this since time immemorial, so I don't think we
need a last minute fix now.

One thing we could do, since all catalog updates now go through
CatalogTupleUpdate(), is not use simple_heap_update() there but do the
heap_update() directly and provide a better user-facing error message.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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