From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Latch implementation that wakes on postmaster death on both win32 and Unix |
Date: | 2011-07-08 09:57:20 |
Message-ID: | CAEYLb_U-34JfnvYg9UWx-PJiwQ+Pjf6q6TnN8iz+B5qr-Vn_ig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7 July 2011 19:15, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I'm not concerned about the possibility of spurious extra cycles of
>> auxiliary process event loops - should I be?
>
> A tight loop would be bad, but an occasional spurious wake-up seems harmless.
We should also assert !PostmasterIsAlive() from within the latch code
after waking due to apparent Postmaster death. The reason that I don't
want to follow Florian's suggestion to check it in production is that
I don't know what to do if the postmaster turns out to be alive. Why
is it more reasonable to try again than to just return? If the
spurious wake-up thing was a problem that we could actually reproduce,
then maybe I'd have an opinion on it. As it stands, our entire basis
for thinking this may be a problem is the sentence "There may be other
circumstances in which a file descriptor is spuriously reported as
ready". That seems rather flimsy.
Anyone that still has any misgivings about this will probably feel
better once the assertion is never reported to fail on any of the
diverse systems that PostgreSQL will be tested on in advance of the
9.2 release.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2011-07-08 10:02:34 | Re: spinlock contention |
Previous Message | Magnus Hagander | 2011-07-08 09:38:38 | Re: Review of VS 2010 support patches |