On Thu, Apr 27, 2017 at 2:48 AM, Andres Freund <andres@anarazel.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs