Re: Latches, loop and exit

Like latches, nice one.

The way the loop in WalSender now happens it won't send any outstanding
WAL if a shutdown is requested while it is waiting.

That probably needs to change and we'd do similarly in other procs.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services

On Wed, Sep 15, 2010 at 12:14 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> Like latches, nice one.
>
> The way the loop in WalSender now happens it won't send any outstanding
> WAL if a shutdown is requested while it is waiting.
>
> That probably needs to change and we'd do similarly in other procs.

Really? ISTM that walsender tries to send all outstanding WAL without
problems after it receives SIGUSR2. Am I missing something?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

On Wed, 2010-09-15 at 10:33 +0900, Fujii Masao wrote:
> On Wed, Sep 15, 2010 at 12:14 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >
> > Like latches, nice one.
> >
> > The way the loop in WalSender now happens it won't send any outstanding
> > WAL if a shutdown is requested while it is waiting.
> >
> > That probably needs to change and we'd do similarly in other procs.
>
> Really? ISTM that walsender tries to send all outstanding WAL without
> problems after it receives SIGUSR2. Am I missing something?

For SIGUSR2, you're right.

However, if the following clause is ever invoked, then the loop does
have problems and we leave when not caught up.

if (!PostmasterIsAlive(true))
exit(1);

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services

On Wed, Sep 15, 2010 at 3:19 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> For SIGUSR2, you're right.
>
> However, if the following clause is ever invoked, then the loop does
> have problems and we leave when not caught up.
>
> if (!PostmasterIsAlive(true))
>        exit(1);

In normal shutdown case, that clause is not invoked since postmaster
exits after walsender exits. That is, the clause is for emergency case,
e.g., case where SIGKILL arrives at postmaster. Even in such an
emergency case, you think walsender should send all outstanding WAL?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

On 15/09/10 09:19, Simon Riggs wrote:
> On Wed, 2010-09-15 at 10:33 +0900, Fujii Masao wrote:
>> On Wed, Sep 15, 2010 at 12:14 AM, Simon Riggs<simon(at)2ndquadrant(dot)com> wrote:
>>>
>>> Like latches, nice one.
>>>
>>> The way the loop in WalSender now happens it won't send any outstanding
>>> WAL if a shutdown is requested while it is waiting.
>>>
>>> That probably needs to change and we'd do similarly in other procs.
>>
>> Really? ISTM that walsender tries to send all outstanding WAL without
>> problems after it receives SIGUSR2. Am I missing something?
>
> For SIGUSR2, you're right.
>
> However, if the following clause is ever invoked, then the loop does
> have problems and we leave when not caught up.
>
> if (!PostmasterIsAlive(true))
> exit(1);

As the comment above that says, that's just an escape hatch if
postmaster dies unexpectedly for any reason. It won't happen in a normal
shutdown.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Wed, 2010-09-15 at 09:40 +0300, Heikki Linnakangas wrote:
> > However, if the following clause is ever invoked, then the loop does
> > have problems and we leave when not caught up.
> >
> > if (!PostmasterIsAlive(true))
> > exit(1);
>
> As the comment above that says, that's just an escape hatch if
> postmaster dies unexpectedly for any reason. It won't happen in a normal
> shutdown.

Thanks for clarifying. I wanted to copy the logic, so just checking.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services