Re: Concurrent ALTER SEQUENCE RESTART Regression
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Michael Paquier <michael.paquier@gmail.com>, Jason Petersen <jason@citusdata.com>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-04-27T06:23:04Z
Lists: pgsql-bugs, pgsql-hackers
On 2017-04-26 22:58:06 -0700, Andres Freund wrote:
> On 2017-04-26 22:07:03 -0400, Peter Eisentraut wrote:
> > On 4/26/17 21:12, Andres Freund wrote:
> > > I think it's unacceptable to regress with an error message here. I've
> > > seen sequence DDL being used while concurrent DML was onging in a number
> > > of production use cases, and just starting to error out instead of
> > > properly blocking doesn't seem acceptable to me.
> >
> > It's not clear to me what the use case is here that we are optimizing
> > for. The best solution would depend on that. Running concurrent ALTER
> > SEQUENCE in a tight loop is probably not it. ;-)
>
> Oh, and there's absolutely no need for a loop or anything:
>
> A: CREATE SEQUENCE someseq
> A: BEGIN;
> A: ALTER SEQUENCE someseq RESTART ;
> B: ALTER SEQUENCE someseq RESTART ;
> A: COMMIT;
> B: ERROR: XX000: tuple concurrently updated
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
Commits
-
Make ALTER SEQUENCE, including RESTART, fully transactional.
- 3d79013b970d 10.0 landed
-
Modify sequence catalog tuple before invoking post alter hook.
- 665104557fdc 10.0 landed
-
Use weaker locks when updating pg_subscription_rel
- 521fd4795e3e 10.0 cited
-
Add pg_sequence system catalog
- 1753b1b02703 10.0 cited
-
Modify sequence state storage to eliminate dangling-pointer problem
- a2597ef17958 7.3.1 cited