Re: SIREAD lock versus ACCESS EXCLUSIVE lock

Kevin Grittner <kevin.grittner@wicourts.gov>

From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Heikki Linnakangas" <heikki.linnakangas@enterprisedb.com>
Cc: "<Simon Riggs" <simon@2ndquadrant.com>, "Dan Ports" <drkp@csail.mit.edu>, <pgsql-hackers@postgresql.org>
Date: 2011-06-03T19:11:21Z
Lists: pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> On 03.06.2011 21:04, Kevin Grittner wrote:
>> Also, if anyone has comments or hints about the placement of
>> those calls, I'd be happy to receive them.
> 
> heap_drop_with_catalog() schedules the relation for deletion at
> the end of transaction, but it's still possible that the
> transaction aborts and the heap doesn't get dropped after all. If
> you put the DropAllPredicateLocksFromTable() call there, and the
> transaction later aborts, you've lost all the locks already.
> 
> I think you'll need to just memorize the lock deletion command in
> a backend-local list, and perform the deletion in a post-commit
> function. Something similar to the PendingRelDelete stuff in
> storage.c. In fact, hooking into smgrDoPendingDeletes would work,
> but that seems like a modularity violation.
 
Thanks.  That's helpful.  Will look at that code and do something
similar.
 
I knew it didn't look right in the place it was, but couldn't quite
see what to do instead....
 
-Kevin