Re: Process wakeups when idle and power consumption - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Process wakeups when idle and power consumption
Date
Msg-id 9038.1304788075@sss.pgh.pa.us
Whole thread Raw
In response to Re: Process wakeups when idle and power consumption  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: Process wakeups when idle and power consumption  (Peter Geoghegan <peter@2ndquadrant.com>)
List pgsql-hackers
Peter Geoghegan <peter@2ndquadrant.com> writes:
> Perhaps I'm missing the point here, but I don't think that I have to
> make an argument for why it might be acceptable to have two archivers
> running at once, or two of any other auxiliary process. Let's assume
> that it's completely unacceptable. It may still be worth while
> applying this patch essentially as-is.

> It's also clearly completely unacceptable to have orphaned regular
> backends running at the same time as another, freshly started sets of
> backends with their own shared buffers that aren't in contact with the
> orphans, but have the same data directory. That's still possible today
> though. This is the main reason that we caution people against kill
> -9'ing the postmaster - if they do so, but then delete postmaster.pid
> before starting a new postmaster, that causes data corruption.

Indeed, which is why we have the postmaster.pid interlock against doing
that.  What you describe is a DBA with a death wish who's going out of
his way to defeat the safety interlock.  We can't do much about that
level of idiocy.  However, it's quite irrelevant to the current
discussion.

The aspect of this that *is* relevant is that if you haven't
deliberately defeated the interlock (and thereby put your data at risk),
you won't be able to start a new postmaster until all the old
shmem-attached children are gone.  And that's why having a child with a
very long reaction time for parent death represents a denial of service.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: a bit more precise MaxOffsetNumber
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade's bindir options could be optional