Re: Excessive PostmasterIsAlive calls slow down WAL redo

On Thu, Apr 19, 2018 at 6:20 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On April 18, 2018 8:05:50 PM PDT, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>>By the way, these patches only use the death signal to make
>>PostmasterIsAlive() fast, for use by busy loops like recovery. The
>>postmaster pipe is still used for IO/timeout loops to detect
>>postmaster death. In theory you could get rid of the postmaster pipe
>>completely when USE_POSTMASTER_DEATH_SIGNAL is defined and make it
>>like the latch code, using the same self-pipe. I'm not sure if there
>>is anything to be gained by that (that wasn't already gained by using
>>epoll/kqueue) so I'm not proposing it.
>
> In my local prototype patch I'd done so. And I think it makes sense, because it's s somewhat contended object, even when using epoll/kqueue. On the other hand, it makes the chide changed a bit harder, making it pretty was were I suspended the work for a bit...

Hmm. I thought the whole idea of these interfaces was "don't call us,
we'll call you" inside the kernel, so you can add thousands of pipes
if you like, but epoll/kevent will only check the queue and then wait
for notification, rather than interacting with the referenced objects?

If that is true, and given that we need to maintain the pipe-based
code anyway for platforms that need it, then what would we gain by
adding a different code path just because we can? Obviously
WaitLatch() (the thing that creates, adds pipe, waits, then destroys
every time) could save time by not having to deal with a postmaster
pipe, but the solution to that is another patch that switches more
things to reusable WES objects.

--
Thomas Munro
http://www.enterprisedb.com