On Wed, 2011-03-16 at 18:41 +0900, Fujii Masao wrote: > 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).
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers