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