On 6 October 2012 22:52, Thom Brown <t...@linux.com> wrote: > On 5 October 2012 15:26, Heikki Linnakangas <heikki.linnakan...@iki.fi> 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. -- Thom -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
