| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, "<Simon Riggs" <simon(at)2ndquadrant(dot)com>, Dan Ports <drkp(at)csail(dot)mit(dot)edu> |
| Subject: | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |
| Date: | 2011-06-03 18:45:56 |
| Message-ID: | 4DE92BE4.6000704@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2011-06-03 18:51:45 | permissions of external PID file |
| Previous Message | Tom Lane | 2011-06-03 18:27:19 | Re: Domains versus polymorphic functions, redux |