| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| 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-10 17:19:40 |
| Message-ID: | 4F846BAC.5020807@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/9/12 6:12 PM, Jeff Davis wrote:
> 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:
Postgres sense. I thought there was concern about multiple people trying to increment or decrement the count at the same time, and if that was the case perhaps there was an issue with it not being in a CRITICAL_SECTION as well. But I could certainly be wrong about this. :)
And yes, we'd definitely not want to be in a CRITICAL_SECTION for the duration of the operation...
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2012-04-10 17:27:16 | Re: Last gasp |
| Previous Message | Christoph Berg | 2012-04-10 17:10:42 | Re: invalid search_path complaints |