| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | <simon(at)2ndquadrant(dot)com>,<drkp(at)csail(dot)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |
| Date: | 2011-06-07 17:03:29 |
| Message-ID: | 4DEE1391020000250003E275@gw.wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> We've also already removed the reserved entry for scratch space
This and Tom's concerns have me wondering if we should bracket the
two sections of code where we use the reserved lock target entry
with HOLD_INTERRUPTS() and RESUME_INTERRUPTS(). In an assert-enable
build we wouldn't really recover from a transaction canceled while
it was checked out (although if that were the only problem, that
could be fixed), but besides that a cancellation while it's checked
out could cause these otherwise-safe functions to throw exceptions
due to a full heap table.
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2011-06-07 17:10:12 | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |
| Previous Message | Robert Haas | 2011-06-07 16:58:49 | Re: reducing the overhead of frequent table locks - now, with WIP patch |