Re: Sync Rep v19

On Fri, 2011-03-04 at 17:34 +0900, Fujii Masao wrote:
> On Fri, Mar 4, 2011 at 3:16 PM, Simon Riggs <simon(at)2ndquadrant(dot)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'm not sure if that matters. Nobody apart from the postmaster knows
about a shutdown. All the other processes know is that they received
SIGTERM, which as you say could have been a specific user action aimed
at an individual process.

We need a way to end the wait state explicitly, so it seems easier to
make SIGTERM the initiating action, no matter how it is received.

The alternative is to handle it this way
1) set something in shared memory
2) set latch of all backends
3) have the backends read shared memory and then end the wait

Who would do (1) and (2)? Not the backend, its sleeping, not the
postmaster its shm, nor a WALSender cos it might not be there.

Seems like a lot of effort to avoid SIGTERM. Do we have a good reason
why we need that? Might it introduce other issues?

> 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()?

Yes, if we don't use SIGTERM then we would use EndCommand()

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