| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Jim Nasby <jim(at)nasby(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Cousin Marc <cousinmarc(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Hans-Juergen Schoenig <hs(at)cybertec(dot)at>, Ants Aasma <ants(at)cybertec(dot)at> |
| Subject: | Re: bug in fast-path locking |
| Date: | 2012-04-09 23:12:12 |
| Message-ID: | 1334013132.5289.86.camel@sussancws0025 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2012-04-09 at 17:42 -0500, Jim Nasby wrote:
> Dumb question... should operations in the various StrongLock functions
> take place in a critical section? Or is that already ensure outside of
> these functions?
Do you mean CRITICAL_SECTION() in the postgres sense (that is, avoid
error paths by making all ERRORs into PANICs and preventing interrupts);
or the sense described here:
http://en.wikipedia.org/wiki/Critical_section ?
If you mean in the postgres sense, you'd have to hold the critical
section open from the time you incremented the strong lock count all the
way until you decremented it (which is normally at the time the lock is
released); which is a cure worse than the disease.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-04-09 23:38:16 | Re: Last gasp |
| Previous Message | Jim Nasby | 2012-04-09 22:42:06 | Re: bug in fast-path locking |