On 2017-05-10 10:29:02 -0400, Tom Lane wrote: > Petr Jelinek <petr.jeli...@2ndquadrant.com> writes: > > On 10/05/17 07:09, Peter Eisentraut wrote: > >> I think the correct fix is to have nextval() and ALTER SEQUENCE use > >> sensible lock levels so that they block each other. Since > >> nextval() currently uses AccessShareLock, the suggestion was for > >> ALTER SEQUENCE to therefore use AccessExclusiveLock. But I think a > >> better idea would be for nextval() to use RowExclusiveLock > >> (analogous to UPDATE) and ALTER SEQUENCE to use > >> ShareRowExclusiveLock, which would also satisfy issue #1. > > > When I proposed this upstream, Andres raised concern about performance > > of nextval() if we do this, did you try to run any benchmark on this? > > As long as it doesn't block, the change in lock strength doesn't actually > make any speed difference does it?
The issue isn't the strength, but that we currently have this weird hackery around open_share_lock(): /* * Open the sequence and acquire AccessShareLock if needed * * If we haven't touched the sequence already in this transaction, * we need to acquire AccessShareLock. We arrange for the lock to * be owned by the top transaction, so that we don't need to do it * more than once per xact. */ This'd probably need to be removed, as we'd otherwise would get very weird semantics around aborted subxacts. Upthread I theorized whether that's actually still meaningful given fastpath locking and such, but I guess we'll have to evaluate that. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
