On Wed, Mar 16, 2011 at 5:44 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, 2011-03-16 at 16:36 +0900, Fujii Masao wrote:
>> On Sat, Mar 12, 2011 at 3:12 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> > There's a comment that looks related to this issue in syncrep.c. It reads:
>> >
>> > /*
>> > * We don't receive SIGHUPs at this point, so resetting
>> > * synchronous_standby_names has no effect on waiters.
>> > */
>> >
>> > It's unclear to me what this actually means. Is there some reason we
>> > CAN'T receive SIGHUPs at that point, or have we just chosen not to
>> > (for unexplained reasons)?
>>
>> Not sure. Simon?
>>
>> It seems harmless to receive SIGHUP at that point.
>
> You pointed out this out to me, so if you want I can explain back to you
> again ;-) Signals are blocked over that section of code.
Yeah, I pointed out that SIGINT and SIGTERM are blocked there.
But not SIGHUP ;)
> We could write a scary bit of code to get around that, but it smells
> badly of kludge.
>
> What do you think we should do?
What I'm thinking is to make the waiting backends get out of the wait
state if synchronous_standby_names is emptied and configuration file
is reloaded. IOW, I'd like to change SyncRepWaitForLSN() so that it
calls ProcessConfigFile() when the flag got_SIGHUP is true, and then
gets out of the wait loop if there is no name in synchronous_standby_names
(i.e., when the variable sync_standbys_defined is FALSE).
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
