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.
What's your proposed fix?
- Andres
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs