Re: Process wakeups when idle and power consumption

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Process wakeups when idle and power consumption
Date: 2011-05-07 17:07:55
Message-ID: 9038.1304788075@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <peter(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-05-07 17:33:15 Re: pg_upgrade's bindir options could be optional
Previous Message Tomas Vondra 2011-05-07 16:56:02 Re: a bit more precise MaxOffsetNumber