On Wed, 2011-03-16 at 18:41 +0900, Fujii Masao wrote:
> 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).
I did try that and it didn't work.
If you think it will, I'll try again.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
