Re: Allow interrupts on waiting standby

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow interrupts on waiting standby
Date: 2017-03-18 20:14:01
Message-ID: 10158.1489868041@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> Both things are fixed in the new version attached. I have added as
> well this patch to the next commit fest:
> https://commitfest.postgresql.org/13/977/

Couple of thoughts on this patch ---

1. Shouldn't WaitExceedsMaxStandbyDelay's CHECK_FOR_INTERRUPTS be moved to
after the WaitLatch call? Not much point in being woken immediately by
an interrupt if you're not going to respond.

2. Is it OK to ResetLatch here? If the only possible latch event in this
process is interrupt requests, then I think WaitLatch, then ResetLatch,
then CHECK_FOR_INTERRUPTS is OK; but otherwise it seems like you risk
discarding events that need to be serviced later.

3. In the same vein, if we're going to check WL_POSTMASTER_DEATH, should
there be a test for that and immediate exit(1) here?

4. I'd be inclined to increase the sleep interval only if we did time out,
not if we were awakened by some other event.

5. The comment about maximum sleep length needs some work. At first
glance you might think that without the motivation of preventing long
uninterruptible sleeps, we might as well allow the sleep length to grow
well past 1s. I think that'd be bad, because we want to wake up
reasonably soon after the xact(s) we're waiting for commit. But neither
the original text nor the proposed replacement mention this.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-03-18 20:23:17 Re: Removing binaries (was: createlang/droplang deprecated)
Previous Message Magnus Hagander 2017-03-18 20:12:40 Removing binaries (was: createlang/droplang deprecated)