Re: Reduced power consumption in WAL Writer process

On Sun, Jul 17, 2011 at 8:20 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> This is a bit of a detour, but probably a useful one. Attached is a
> patch that replaces a tight PostmasterIsAlive() polling loop in the AV
> launcher with a latch, making use of the new WL_POSTMASTER_DEATH
> functionality. It's similar to what we've already done for the
> archiver. It is relatively straightforward as these auxiliary process
> polling loop elimination patches go (certainly compared to what we're
> contemplating with the WAL writer), but it raises some questions that
> we were lucky to have been able to avoid when I worked on the
> archiver. Obviously, this patch isn't finished.

Might be good to start a new thread for each auxilliary process, or we
may get confused.

> We register various generic signal handlers for the AVLauncher,
> including StatementCancelHandler(). Of course, signals that are
> handled generically have the same potential to invalidate WaitLatch()
> timeout as any other type of signal. We should be mindful of this.

Right.

> ISTM that these generic handlers ought to be handling this
> generically, and that there should be a Latch for just this purpose
> for each process within PGPROC. We already have this Latch in PGPROC:
>
> Latch           waitLatch;              /* allow us to wait for sync rep */
>
> Maybe its purpose should be expanded to "current process Latch"?

I think that could be a really good idea, though I haven't looked at
it closely enough to be sure.

> Another concern is, what happens when we receive a signal, generically
> handled or otherwise, and have to SetLatch() to avoid time-out
> invalidation? Should we just live with a spurious
> AutoVacLauncherMain() iteration, or should we do something like check
> if the return value of WaitLatch indicates that we woke up due to a
> SetLatch() call, which must have been within a singal handler, and
> that we should therefore goto just before WaitLatch() and elide the
> spurious iteration? Given that we can expect some signals to occur
> relatively frequently, spurious iterations could be a real concern.

Really? I suspect that it doesn't much matter exactly how many
machine language instructions we execute on each wake-up, within
reasonable bounds, of course. Maybe some testing is in order?

On another note, I might be inclined to write something like:

if ((return_value_of_waitlatch & WL_POSTMASTER_DEATH) && !PostmasterIsAlive())
proc_exit(1);

...so as to avoid calling that function unnecessarily on every iteration.

> Incidentally, should I worry about the timeout long for WaitLatch()
> overflowing?

How would that happen?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company