From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Use the regular main processing loop also in walsenders. |
Date: | 2012-10-07 09:24:48 |
Message-ID: | CAA-aLv4nWVcnt0XmyGshwc15w1i7O9D4ybkbhu4+m5Th5F-XMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 6 October 2012 22:52, Thom Brown <thom(at)linux(dot)com> wrote:
> On 5 October 2012 15:26, Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2012-10-07 14:41:26 | pgsql: Fix compiling errors on Windows platform. Fix wrong usage of |
Previous Message | Tatsuo Ishii | 2012-10-07 00:41:08 | Re: [COMMITTERS] pgsql: Bump up catalog vesion due to 64-bit large object API functions |