| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, 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-04 16:19:04 |
| Message-ID: | 26005.1307204344@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> 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.
But on the third thought: is that wrong? Surely locks taken by an
aborted transaction can be discarded.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2011-06-04 16:20:52 | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |
| Previous Message | Heikki Linnakangas | 2011-06-04 15:44:07 | Re: reducing the overhead of frequent table locks - now, with WIP patch |