Re: Sync Rep v19

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep v19
Date: 2011-03-04 06:16:08
Message-ID: 1299219368.10703.2838.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2011-03-04 at 13:35 +0900, Fujii Masao wrote:
> On Fri, Mar 4, 2011 at 1:27 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > On Fri, Mar 4, 2011 at 7:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> >>> Anyway, this is code in the interrupt handler and only gets executed
> >>> when we receive SIGTERM for a fast shutdown.
> >>
> >> I trust it's not getting *directly* executed from the interrupt handler,
> >> at least not without ImmediateInterruptOK.
> >
> > Yes, the backend waits for replication while cancel/die interrupt is
> > being blocked, i.e., InterruptHoldoffCount > 0. So SIGTERM doesn't
> > lead the waiting backend to there directly. The backend reaches there
> > after returning the result.
>
> BTW, this is true in COMMIT and PREPARE cases,

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.

> and false in
> COMMIT PREPARED and ROLLBACK PREPARED cases. In the
> latter cases, HOLD_INTERRUPT() is not called before waiting for
> replication.

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

Attachment Content-Type Size
signal_filter.patch text/x-patch 868 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-03-04 07:03:14 Re: why is max standby delay only 35 minutes?
Previous Message Fujii Masao 2011-03-04 04:35:17 Re: Sync Rep v19