From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Jason Petersen <jason(at)citusdata(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression |
Date: | 2017-05-18 20:54:28 |
Message-ID: | 20170518205428.kxxtsdl6wswnz3e3@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On 2017-05-15 10:34:02 -0400, Peter Eisentraut wrote:
> On 5/10/17 09:12, Michael Paquier wrote:
> > Looking at 0001 and 0002... So you are correctly blocking nextval()
> > when ALTER SEQUENCE holds a lock on the sequence object. And
> > concurrent calls of nextval() don't conflict. As far as I can see this
> > matches the implementation of 3.
> >
> > Here are some minor comments.
>
> Committed after working in your comments. Thanks!
There's still weird behaviour, unfortunately. If you do an ALTER
SEQUENCE changing minval/maxval w/ restart in a transaction, and abort,
you'll a) quite possibly not be able to use the sequence anymore,
because it may of bounds b) DDL still isn't transactional.
At the very least that'd need to be documented.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2017-05-19 10:07:59 | Re: Re: [BUGS] BUG #14657: Server process segmentation fault in v10, May 10th dev snapshot |
Previous Message | Vitaliy Gomenyuk | 2017-05-18 16:26:29 | Re: BUG #14635: Query is executed slower on hot standby slave database then on master database |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-05-18 22:06:16 | Re: pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.) |
Previous Message | Piotr Stefaniak | 2017-05-18 20:51:48 | Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run. |