On 8 October 2012 11:34, Heikki Linnakangas <[email protected]> wrote: > On 07.10.2012 12:24, Thom Brown wrote: >> >> On 6 October 2012 22:52, Thom Brown<[email protected]> wrote: >>> >>> On 5 October 2012 15:26, Heikki Linnakangas<[email protected]> >>> wrote: >>>> >>>> Use the regular main processing loop also in walsenders. >>>> >>>> The regular backend's main loop handles signal handling and error >>>> recovery >>>> better than the current WAL sender command loop does. For example, if >>>> the >>>> client hangs and a SIGTERM is received before starting streaming, the >>>> walsender will now terminate immediately, rather than hang until the >>>> connection times out. >>> >>> >>> This commit seems to have broken the WAL sender in at least one >>> scenario. I have a primary and 2 standbys, standby 1 receiving WAL >>> stream from the primary, and standby 2 receiving WAL stream from >>> standby 1 (chain configuration). If I attempt to restart standby 1, >>> it hangs and the WAL sender process on standby 1 uses 100% CPU. >>> >>> The following error is logged too: >>> FATAL: terminating walreceiver process due to administrator command >>> >>> I can shut down standby 1 without issue only if I shut down standby 2 >>> before it. >> >> >> This was just a description of the scenario I was using. The same >> occurs with just 1 standby and attempting to shut down the primary. > > > Fixed, thanks for the report. I set ProcDiePending = true to kill the > process, but that didn't do anything without also setting InterruptPending = > true. On second thoughts, it wasn't a very good way to make walsender exit, > anyway, so I changed it to use proc_exit(0), like it used to.
Thanks. -- Thom -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
