From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Jason Petersen <jason(at)citusdata(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Concurrent ALTER SEQUENCE RESTART Regression |
Date: | 2017-05-01 17:49:28 |
Message-ID: | 20170501174928.gzv7o6l4bushzcb3@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 2017-04-30 12:00:47 +0200, Petr Jelinek wrote:
> On 28/04/17 09:55, Michael Paquier wrote:
> > On Thu, Apr 27, 2017 at 4:10 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> On April 27, 2017 12:06:55 AM PDT, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
> >>> On Thu, Apr 27, 2017 at 3:23 PM, Andres Freund <andres(at)anarazel(dot)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.
> >
>
> The question is if we want the metadata update to be transactional or
> not (I don't know what was Peter's goal here). If we did want
> transactionality, we'd have to change lock levels for the sequence
> relation in ALTER SEQUENCE so that it blocks other ALTERs and nextval().
Well, previously it wasn't transactional and didn't block, but largely
consistently so. Now it's a weird mix: RESTART is not transactional,
MAXVAL etc are transactional - even when done at the same time as
RESTART -, but don't block, so you get inconsistent results until the
transaction commits. And you get failures that are not consistent with
transactional DDL.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-05-02 02:10:36 | Re: Concurrent ALTER SEQUENCE RESTART Regression |
Previous Message | Adrian Klaver | 2017-05-01 13:20:54 | Re: BUG #14636: pg_dumpall -d |
From | Date | Subject | |
---|---|---|---|
Next Message | Mikael Kjellström | 2017-05-01 18:13:02 | Re: [buildfarm-members] BuildFarm client release 4.19 |
Previous Message | Peter Eisentraut | 2017-05-01 17:43:54 | Re: Re: logical replication and PANIC during shutdown checkpoint in publisher |