Horton

Re: 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: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Michael Paquier <michael.paquier@gmail.com>, Jason Petersen <jason@citusdata.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-05-02T18:40:38Z
Lists: pgsql-bugs, pgsql-hackers 
On Tue, May 2, 2017 at 1:36 PM, Andres Freund <andres@anarazel.de> wrote:
>> But by the same token surely we don't want to do
>> CatalogUpdateIndexes() while holding the buffer lock either; mutual
>> exclusion needs to be managed at some higher level, using, say, a
>> heavyweight tuple lock.
>
> Right, I don't want that to happen - I think it means we need a proper
> lock here, but Peter seems to be against that for reasons I don't
> understand.  It's what Michael had suggested in:
> http://archives.postgresql.org/message-id/CAB7nPqRev_wK4k39hQBpQZRQ17v29guxfobnnmTYT_-hUU67BA%40mail.gmail.com

Yes, I didn't understand Peter's objection, either.  It's true that
there are multiple levels of locks here, but if we've got things
failing that used to work, then we've not got all the right ones.

-- 
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