Re: How should the waiting backends behave in sync rep?

On Wed, Mar 16, 2011 at 5:44 PM, Simon Riggs <simon(at)2ndquadrant(dot)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(at)gmail(dot)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