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
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 |