Re: Process wakeups when idle and power consumption

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Process wakeups when idle and power consumption
Дата
Msg-id 9038.1304788075@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Process wakeups when idle and power consumption  (Peter Geoghegan <peter@2ndquadrant.com>)
Ответы Re: Process wakeups when idle and power consumption
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: a bit more precise MaxOffsetNumber
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade's bindir options could be optional