Re: Sync Rep v19 - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Sync Rep v19
Date
Msg-id AANLkTik2e04oyaozgZ8hXSeVTwhsRmZPiqcJ5+1-3WEK@mail.gmail.com
Whole thread Raw
In response to Re: Sync Rep v19  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Sync Rep v19
List pgsql-hackers
On Fri, Mar 4, 2011 at 3:16 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> CommitTransaction() calls HOLD_INTERRUPT() and then RESUME_INTERRUPTS(),
> which was reasonable before we started waiting for syncrep. The
> interrupt does occur *before* we send the message back, but doesn't work
> effectively at interrupting the wait in the way you would like.
>
> If we RESUME_INTERRUPTS() prior to waiting and then HOLD again that
> would allow all signals not just SIGTERM. We would need to selectively
> reject everything except SIGTERM messages.
>
> Ideas?
>
> Alter ProcessInterrupts() to accept an interrupt if ProcDiePending &&
> WaitingForSyncRep and InterruptHoldoffCount > 0. That looks a little
> scary, but looks like it will work.

If shutdown is requested before WaitingForSyncRep is set to TRUE and
after HOLD_INTERRUPT() is called, the waiting backends cannot be
interrupted.

SIGTERM can be sent by pg_terminate_backend(). So we should check
whether shutdown is requested before emitting WARNING and closing
the connection. If it's not requested yet, I think that it's safe to return the
success indication to the client.

I think that it's safer to close the connection and terminate the backend
after cleaning all the resources. So, as I suggested before, how about
doing that in EndCommand()?

Regards,

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


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: How should the primary behave when the sync standby goes away? Re: Sync Rep v17
Next
From: daveg
Date:
Subject: Re: Re: PD_ALL_VISIBLE flag was incorrectly set happend during repeatable vacuum