From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Jason Petersen <jason(at)citusdata(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Concurrent ALTER SEQUENCE RESTART Regression |
Date: | 2017-04-26 23:12:30 |
Message-ID: | CAB7nPqR_K5pSnP9WUyvgn_76Qurz7BtJZgF6tL1+3cFwxwj68w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Thu, Apr 27, 2017 at 2:48 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2017-04-26 12:15:53 -0400, Peter Eisentraut wrote:
>> On 4/25/17 21:24, Michael Paquier wrote:
>> > Yes, and that's fine, taking a stronger lock on pg_sequence would be
>> > disruptive for other sessions, including the ones updating pg_sequence
>> > for different sequences. The point I am trying to make here is that
>> > the code path updating pg_sequence should make sure that the
>> > underlying object is properly locked first, so as the update is
>> > concurrent-safe because this uses simple_heap_update that assumes that
>> > the operation will be concurrent-safe. For example, take tablecmds.c,
>> > we make sure that any relation ALTER TABLE works on gets a proper lock
>> > with relation_open first, in what sequences would be different now
>> > that they have their own catalog?
>>
>> Pretty much everything other than tables is a counterexample.
>>
>> git grep RowExclusiveLock src/backend/commands/*.c
>>
>> Only tables have an underlying object to lock. Most other DDL commands
>> don't have anything else to lock and run DDL under RowExclusiveLock.
Well, there are more DDL commands where it is possible to see "tuple
concurrently updated" easily, an example is ALTER ROLE. So nothing is
concurrent-proof with this code and I think needs a careful lookup
because this error should never be something that is user-visible.
> What's your proposed fix?
Extra opinions/ideas are welcome.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Pietro Pugni | 2017-04-26 23:16:13 | Re: BUG #14632: Plus and minus operators inconsistency with leap years and year intervals. |
Previous Message | Marko Tiikkaja | 2017-04-26 23:08:32 | Re: BUG #14632: Plus and minus operators inconsistency with leap years and year intervals. |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-04-26 23:18:56 | Re: Logical replication in the same cluster |
Previous Message | David Rowley | 2017-04-26 23:09:51 | Re: Foreign Join pushdowns not working properly for outer joins |