"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
> Tom Lane <t...@sss.pgh.pa.us> wrote:
>> At least on Unix I don't believe there is any other solution. You
>> could try looking at ps output but there's a fundamental race
>> condition, ie the postmaster could spawn another child just before
>> you kill it, whereupon the child is reassigned to init and there's
>> no longer a good way to tell that it came from that postmaster.
> Couldn't you run `ps auxf` and kill any postgres process which is
> not functioning as postmaster (those are pretty easy to distinguish)
> and which isn't the child of such a process? Is there ever a reason
> to allow such an orphan to run?
That's not terribly hard to do by hand, especially since the cautious
DBA could also do things like checking a process' CWD to verify which
postmaster it had belonged to. I can't see automating it though.
We already have a perfectly good solution to the automated shutdown
problem.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
