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
> does
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 t
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
>Tom Lane
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I don't think we want that. IMHO the preferred behavior if the
> >> postmaster crashes should be like a "smart shutdown" --- you don't
> spawn
> >> any more backends (obviously) but existing backends should be
allowed
> to
"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 reli
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 st
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 proces
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 l
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
> post
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
pr
> > I don't think we want that. IMHO the preferred behavior if the
> > postmaster crashes should be like a "smart shutdown" --- you don't spawn
> > any more backends (obviously) but existing backends should be allowed to
> > run until their clients exit. That's how things have always worked
> > a
Jan Wieck <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't think we want that. IMHO the preferred behavior if the
>> postmaster crashes should be like a "smart shutdown" --- you don't spawn
>> any more backends (obviously) but existing backends should be allowed to
>> run until their clien
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 c
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 k
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
h
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
16 matches
Mail list logo
