Horton

Re: Concurrent ALTER SEQUENCE RESTART Regression

Michael Paquier <michael.paquier@gmail.com>

View thread View on postgr.es
From: Michael Paquier <michael.paquier@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Jason Petersen <jason@citusdata.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-04-28T07:55:45Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

On Thu, Apr 27, 2017 at 4:10 PM, Andres Freund <andres@anarazel.de> wrote:
> On April 27, 2017 12:06:55 AM PDT, Michael Paquier <michael.paquier@gmail.com> wrote:
>>On Thu, Apr 27, 2017 at 3:23 PM, Andres Freund <andres@anarazel.de>
>>wrote:
>>> More fun:
>>>
>>> A: CREATE SEQUENCE someseq;
>>> A: BEGIN;
>>> A: ALTER SEQUENCE someseq MAXVALUE 10;
>>> B: SELECT nextval('someseq') FROM generate_series(1, 1000);
>>>
>>> => ignores maxvalue
>>
>>Well, for this one that's because the catalog change is
>>transactional...
>
> Or because the locking model is borked.

The operation actually relies heavily on the fact that the exclusive
lock on the buffer of pg_sequence is hold until the end of the catalog
update. And using heap_inplace_update() seems mandatory to me as the
metadata update should be non-transactional, giving the attached. I
have added some isolation tests. Thoughts? The attached makes HEAD map
with the pre-9.6 behavior.
-- 
Michael

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