Re: Process wakeups when idle and power consumption

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Process wakeups when idle and power consumption
Date: 2011-05-06 14:14:26
Message-ID: BANLkTikVoqFYA4CkGjoTp-nuqw6A=KXuag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 6, 2011 at 10:13 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, May 6, 2011 at 8:16 AM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
>> 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? So control in the archiver is going to stay in its event
>> loop for longer than it would have before, until pgarch_MainLoop()
>> finally returns. The DBA might be required to kill the archiver where
>> before they wouldn't have been (they wouldn't have had time to), but
>> they are also required to kill other backends anyway before deleting
>> postmaster.pid, or there will be dire consequences. Nothing important
>> happens after waiting on the latch but before checking
>> PostmasterIsAlive(), and nothing important happens after the
>> postmaster is found to be dead. ISTM that it wouldn't be particularly
>> bad if the archiver was SIGKILL'd while waiting on a latch.
>
> Well, IMHO, the desirable state of affairs is for all child processes,
> including regular backends, to exit near-instantaneously once the
> postmaster dies.  Among many other problems, once the postmaster is
> gone, there's no guard against shared memory corruption.  And as long
> as there is at least one backend kicking around attached to shared
> memory, you won't be able to restart postmaster, which is something
> you typically want to do as quickly as humanly possible.
>
> http://www.postgresql.org/support/submitbug

The apparently irrelevant link at the bottom of this email is the
result of a cut-and-paste into the wrong email window. Sorry....

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2011-05-06 14:42:36 Re: Visibility map and hint bits
Previous Message Robert Haas 2011-05-06 14:13:33 Re: Process wakeups when idle and power consumption