Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
От | Andres Freund |
---|---|
Тема | Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression |
Дата | |
Msg-id | 20170427062304.gxh3rczhh6vblrwh@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
|
Список | 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 по дате отправления: