Peter Geoghegan <pe...@2ndquadrant.com> writes: > On 5 May 2011 21:05, Tom Lane <t...@sss.pgh.pa.us> wrote: >> The major problem I'm aware of for getting rid of periodic wakeups is >> the need for child processes to notice when the postmaster has died >> unexpectedly.
> Could you please expand upon this? Why is it of any consequence if the > archiver notices that the postmaster is dead after 60 seconds rather > than after 1? Because somebody might try to start a new postmaster before that, and it's not really a good idea to have a rogue archiver running in addition to the new one. You might be able to construct an argument about how that was safe, but it would be a fragile one. What's more, it would not apply to any other child process, and we need a solution that scales to all the children or we're going nowhere in terms of saving power. In the case of the children that are connected to shared memory, such as bgwriter, a long delay until child exit means a long delay until a new postmaster can start at all --- which means you're effectively creating a denial of service, with the length directly proportional to how aggressively you're trying to avoid "unnecessary" wakeups. So that's not a tradeoff I want to be making. I'd rather have a solution in which children somehow get notified of postmaster death without having to wake up just to poll for it. Then, once we fix the other issues, there are no timeouts needed at all, which is obviously the ideal situation for power consumption as well as response time. > The only salient thread I found concerning the problem of making > children know when the postmaster died is this one: > http://archives.postgresql.org/pgsql-hackers/2010-12/msg00401.php You didn't look terribly hard then. Here are two recent threads: http://archives.postgresql.org/pgsql-hackers/2011-01/msg01011.php http://archives.postgresql.org/pgsql-hackers/2011-02/msg02142.php The pipe solution mentioned in the first one would work on all Unixen, and we could possibly optimize things a bit on Linux using the second method. (There was also a bit of speculation about relying on SEM_UNDO, but I don't think we followed that idea far.) I don't know however what we'd need on Windows. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers