On Thu, Feb 26, 2004 at 17:09:21 -0500,
Tom Lane [EMAIL PROTECTED] wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Should we have a pgmon process that watches the postmaster
and restarts it if required?
I doubt it; in practice the postmaster is *very* reliable (because it
doesn't do much),
Tom,
... In the case of a postmaster crash, I think
something in the system is so wrong that I'd prefer an immediate shutdown.
Surely some other people have opinions on this? Hello out there?
Well, my opinion is based on the question, can we restart the postmaster if it
dies and the
Josh Berkus [EMAIL PROTECTED] writes:
Well, my opinion is based on the question, can we restart the
postmaster if it dies and the other backends are still running?
You can't start a fresh postmaster until the last of the old backends is
gone (and yes, there's an interlock to prevent you from
Simon Riggs [EMAIL PROTECTED] writes:
Should we have a pgmon process that watches the postmaster
and restarts it if required?
I doubt it; in practice the postmaster is *very* reliable (because it
doesn't do much), and so I'm not sure that adding a watchdog is going to
increase the net
On Tuesday 24 February 2004 23:47, Neil Conway wrote:
Jan Wieck [EMAIL PROTECTED] writes:
In the case of a postmaster crash, I think something in the system
is so wrong that I'd prefer an immediate shutdown.
I agree. Allowing existing backends to commit transactions after the
postmaster
At 12:19 AM 26/02/2004, Robert Treat wrote:
Yes, roll back any existing/uncommited transactions and shutdown
I'm not event sure I'd go with the rollback; whatever killed the PM may
make the rest of the system unstable. I'd prefer to see the transactions
rolled back (if necessary) as part of the
Philip Warner [EMAIL PROTECTED] writes:
I'm not event sure I'd go with the rollback; whatever killed the PM may
make the rest of the system unstable. I'd prefer to see the transactions
rolled back (if necessary) as part of the log recovery on PM startup, not
by possibly dying PG proceses.
At 04:01 PM 26/02/2004, Tom Lane wrote:
there is no basis for assuming that a postmaster failure has
anything to do with problems at the backend levelSo my
opinion is that kill all the backends when the postmaster
crashes is a bad idea
Sounds fine. Then a system that will allow a new PM to
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
Maybe there should be a provision similar to the stats collector's
check-for-read-ready-from-a-pipe?
the case of the bgwriter is a bit of a twist here. In contrast to the
collectors it is connected to the shared memory. So it
Jan Wieck [EMAIL PROTECTED] writes:
In the case of a postmaster crash, I think something in the system
is so wrong that I'd prefer an immediate shutdown.
I agree. Allowing existing backends to commit transactions after the
postmaster has died doesn't strike me as being that useful, and is
I noticed while doing some debugging this morning that if the postmaster
crashes for some reason (eg kill -9) the bgwriter process never goes
away. Backends will eventually exit when their clients quit, and the
stats collection processes shut down nicely, but the bgwriter process
has to be killed
Tom Lane wrote:
I noticed while doing some debugging this morning that if the postmaster
crashes for some reason (eg kill -9) the bgwriter process never goes
away. Backends will eventually exit when their clients quit, and the
stats collection processes shut down nicely, but the bgwriter process
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
Maybe there should be a provision similar to the stats collector's
check-for-read-ready-from-a-pipe?
the case of the bgwriter is a bit of a twist here. In contrast to the
collectors it is connected to the shared memory. So it can keep
13 matches
Mail list logo
