On Thu, Apr 19, 2018 at 6:20 PM, Andres Freund <and...@anarazel.de> wrote: > On April 18, 2018 8:05:50 PM PDT, Thomas Munro > <thomas.mu...@enterprisedb.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
