On Wed, Mar 16, 2011 at 5:44 PM, Simon Riggs <si...@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 <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
