Re: Process wakeups when idle and power consumption

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> On 5 May 2011 21:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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