On Sun, Mar 19, 2017 at 5:14 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Couple of thoughts on this patch ---
Thanks! > 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. Right, I have switched to WaitLatch(), ResetLatch() and then CHECK_FOR_INTERRUPTS(). > 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? OK, if the postmaster has died, there is not much recovery conflict needed anyway. > 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. OK, that makes sense. > 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. OK, I did some work on this comment. What do you think about the updated version attached? -- Michael
standby-delay-latch-v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
