Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression - Mailing list pgsql-bugs

From Andres Freund
Subject Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
Date
Msg-id 20170427062304.gxh3rczhh6vblrwh@alap3.anarazel.de
Whole thread Raw
In response to Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression  (Andres Freund <andres@anarazel.de>)
Responses Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
List pgsql-bugs
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


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
Next
From: Michael Paquier
Date:
Subject: Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression