detecting a dead db not seeming to work

[Graeme Hinchliffe]

Hiya
I have now managed to get my code to function correctly for a none
present db, and one that is shutdown whilst it is being used. In both
cases my code functions and happily recovers on the db's return.

However one of the tests I performed was to kill -9 the postmaster
process to see how it would handle that (assuming the same behaviour).
However nothing happens! no segfault, no db connection failure etc.
Also what is weird is that even once I have removed the pid file from
/var/run I cannot restart postgres with the /etc/init.d/postgres
script! It claims postgres is running...

If I kill my daemon which is trying to talk to it, postgres starts
without problem agian!

it's as though my daemon trying to talk to it is keeping the connection
open and preventing the db from being started!

I am running postgres 7.3.4 under redhat 9.

Any idea whats going on? or suggestions?

Thanks

--
-----
Graeme Hinchliffe (BSc)
Core Internet Systems Designer
Zen Internet (http://www.zen.co.uk/)

Direct: 0845 058 9074
Main : 0845 058 9000
Fax : [phone]

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postg resql.org

[Tom Lane]

Graeme Hinchliffe <gr************ ***@zeninternet .co.uk> writes:

However one of the tests I performed was to kill -9 the postmaster
process to see how it would handle that (assuming the same behaviour).
However nothing happens! no segfault, no db connection failure etc.
That's the intended behavior on postmaster crash. It doesn't (and
shouldn't) affect existing backends.
If I kill my daemon which is trying to talk to it, postgres starts
without problem agian!
it's as though my daemon trying to talk to it is keeping the connection
open and preventing the db from being started!

A new postmaster can't start until the last old backend is gone. This
is a necessary interlock to avoid data corruption.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Graeme Hinchliffe]

On Thu, 2004-08-26 at 15:57, Tom Lane wrote:

Graeme Hinchliffe <gr************ ***@zeninternet .co.uk> writes:

However one of the tests I performed was to kill -9 the postmaster
process to see how it would handle that (assuming the same behaviour).
However nothing happens! no segfault, no db connection failure etc.

That's the intended behavior on postmaster crash. It doesn't (and
shouldn't) affect existing backends.

indeed, but I need to be able to see that it's dead so I can then try
and reconnect. What is the name of the process that will be holding the
connection open? by kill -9 ing the process I am trying to simulate a
failure case.

If I kill my daemon which is trying to talk to it, postgres starts
without problem agian!
it's as though my daemon trying to talk to it is keeping the connection
open and preventing the db from being started!

A new postmaster can't start until the last old backend is gone. This
is a necessary interlock to avoid data corruption.

But I kill -9 the postmaster, and I cannot start a fresh one, so my
process is sat in limbo, thinking it is talking to a db that isn't there
:).

Well I think so, although I suspect that some part of the db is still
there and running?

--
-----
Graeme Hinchliffe (BSc)
Core Internet Systems Designer
Zen Internet (http://www.zen.co.uk/)

Direct: 0845 058 9074
Main : 0845 058 9000
Fax : [phone]

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Tom Lane]

Graeme Hinchliffe <gr************ ***@zeninternet .co.uk> writes:

On Thu, 2004-08-26 at 15:57, Tom Lane wrote:

A new postmaster can't start until the last old backend is gone. This
is a necessary interlock to avoid data corruption.

But I kill -9 the postmaster, and I cannot start a fresh one, so my
process is sat in limbo, thinking it is talking to a db that isn't there
:). Well I think so, although I suspect that some part of the db is still
there and running?

Certainly --- the backend that's serving your connection. See
http://www.postgresql.org/docs/7.4/s...ect-estab.html

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings