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  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression