On 2017-05-11 11:35:22 -0400, Peter Eisentraut wrote: > On 5/10/17 12:24, Andres Freund wrote: > > 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. > > Can you explain in more detail what you mean by this?
Well, right now we don't do proper lock-tracking for sequences, always assigning them to the toplevel transaction. But that doesn't seem proper when nextval() would conflict with ALTER SEQUENCE et al, because then locks would continue to be held by aborted savepoints. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
