Skip site navigation (1) Skip section navigation (2)

Re: Latch implementation that wakes on postmaster death on both win32 and Unix

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Florian Pflug <fgp(at)phlo(dot)org>
Subject: Re: Latch implementation that wakes on postmaster death on both win32 and Unix
Date: 2011-06-24 11:30:32
Message-ID: BANLkTikY=+dOLQgjtQtYB-01K7QUs0Cvjg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Jun 22, 2011 at 9:11 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
>>                rc = WaitForMultipleObjects(numevents, events, FALSE,
>>                                                           (timeout >= 0) ? (timeout / 1000) : INFINITE);
>> -               if (rc == WAIT_FAILED)
>> +               if ( (wakeEvents & WL_POSTMASTER_DEATH) &&
>> +                        !PostmasterIsAlive(true))
>>
>> After WaitForMultipleObjects() detects the death of postmaster,
>> WaitForSingleObject()
>> is called in PostmasterIsAlive(). In this case, what code does
>> WaitForSingleObject() return?
>> I wonder if WaitForSingleObject() returns the code other than
>> WAIT_TIMEOUT and really
>> can detect the death of postmaster.
>
> As noted up-thread, the fact that the archiver does wake and finish on
> Postmaster death can be clearly observed on Windows. I'm not sure why
> you wonder that, as this is fairly standard use of
> PostmasterIsAlive().

Because, if PostmasterHandle is an auto-reset event object, its event state
would be automatically reset just after WaitForMultipleObjects() detects
the postmaster death event, I was afraid. But your observation proved that
my concern was not right.

I have another comments:

+#ifndef WIN32
+	/*
+	 * Initialise mechanism that allows waiting latch clients
+	 * to wake on postmaster death, to finish their
+	 * remaining business
+	 */
+	InitPostmasterDeathWatchHandle();
+#endif

Calling this function before creating TopMemoryContext looks unsafe. What if
the function calls ereport(FATAL)?

That ereport() can be called before postgresql.conf is read, i.e., before GUCs
for error reporting are set. Is this OK? If not,
InitPostmasterDeathWatchHandle()
should be moved after SelectConfigFiles().

+#ifndef WIN32
+int postmaster_alive_fds[2];
+#endif

postmaster_alive_fds[] should be initialized to "{-1, -1}"?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

pgsql-hackers by date

Next:From: Peter GeogheganDate: 2011-06-24 12:08:28
Subject: Re: Latch implementation that wakes on postmaster death on both win32 and Unix
Previous:From: Noah MischDate: 2011-06-24 11:24:33
Subject: Re: Another issue with invalid XML values

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group