Skip site navigation (1) Skip section navigation (2)

Re: pgsql: Use the regular main processing loop also in walsenders.

From: Thom Brown <thom(at)linux(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Use the regular main processing loop also in walsenders.
Date: 2012-10-08 10:39:49
Message-ID: CAA-aLv6hn4DjfRUUvkwNYt2rAzJLcUa6Jm9gd8jxZbtFEVbkUg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committers
On 8 October 2012 11:34, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
> On 07.10.2012 12:24, Thom Brown wrote:
>>
>> 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.
>
>
> 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


In response to

pgsql-committers by date

Next:From: Heikki LinnakangasDate: 2012-10-08 11:26:09
Subject: pgsql: Say ANALYZE, not VACUUM,in error message on analyze in hot stan
Previous:From: Heikki LinnakangasDate: 2012-10-08 10:34:07
Subject: Re: pgsql: Use the regular main processing loop also in walsenders.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group