Re: [HACKERS] funny lock mode in DropTrigger
Alvaro Herrera writes: > Ah, I also noticed that the ALTER EXTENSION and SECURITY LABEL commands > use ShareUpdateExclusiveLock, and they failed when committed to note > this in the 13.3 chapter of the docs. Not sure how strict we are about > documenting these things. (I note COMMENT already fails to document its > ShareUpdExcl lock). To my mind, the list in 13.3 is only meant to cover what lock levels are used *with tables*. Locks applied to other kinds of objects would probably need a different list altogether. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] funny lock mode in DropTrigger
Alvaro Herrera writes: > I just noticed that DropTrigger uses ShareRowExclusiveLock to lock the > relation it's going to drop the trigger on. The comment right above it > says that this should match RemoveTriggerById, but that one uses > AccessExclusiveLock -- so one of them (or the comment) is not right. Yeah, this is a bug. I think what happened is: 1. Simon committed his patch to reduce lock levels. 2. Robert copied that lock level in his commit 4240e429d0c2d889d0cda23c618f94e12c13ade7 that refactored use of RangeVarGetRelid. 3. When I reverted most of Simon's change, it didn't occur to me to look for places that had copied the bad lock levels --- I was just looking at what his patch had done. I will fix this, and also do some looking to see if the bogus lock levels propagated anywhere else... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] funny lock mode in DropTrigger
Excerpts from Alvaro Herrera's message of vie oct 21 00:40:26 -0300 2011: > Besides, the docs state that no backend code uses ShareRowExclusiveLock > anyway (13.3 Explicit locking). I guess that if the patch to reduce > lock strength in alter table goes in again, it'll need to update this > chapter to match. Ah, I also noticed that the ALTER EXTENSION and SECURITY LABEL commands use ShareUpdateExclusiveLock, and they failed when committed to note this in the 13.3 chapter of the docs. Not sure how strict we are about documenting these things. (I note COMMENT already fails to document its ShareUpdExcl lock). -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
