Re: HEADS UP: Win32/OS2/BeOS native ports - Mailing list pgsql-hackers

From Tom Lane
Subject Re: HEADS UP: Win32/OS2/BeOS native ports
Date
Msg-id 5142.1020694663@sss.pgh.pa.us
Whole thread Raw
In response to Re: HEADS UP: Win32/OS2/BeOS native ports  ("Marc G. Fournier" <scrappy@hub.org>)
Responses Re: HEADS UP: Win32/OS2/BeOS native ports  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: HEADS UP: Win32/OS2/BeOS native ports  (Matthew Kirkwood <matthew@hairy.beasts.org>)
List pgsql-hackers
"Marc G. Fournier" <scrappy@hub.org> writes:
>> Hmm ... but how do you use that to tell if there are still backends
>> around?

> As a backend is started up, connect to that socket ... if socket is open
> when trying to start a new frontend, fail as there are currently other
> connections attached to it?

But the backends would only have the socket open, they'd not be actively
listening to it.  So how could you tell whether anyone had the socket
open or not?

ISTM we gave up on exactly that technique for the main postmaster's
socket; we now create a separate lockfile to protect the socket, and
don't rely on the socket itself to give us any interlocking help at all.
But the lockfile just contains the postmaster's PID, so it's no help
in detecting the case where the old postmaster has gone away but there
are still orphaned backends laying about.

I'm not entirely thrilled with the lockfile technique; it'd be nice to
find something better.  (In particular, we've seen a couple cases now
where people had trouble with PG refusing to start after a system
reboot, because some other daemon process had been assigned the PID
that the postmaster had in its previous incarnation; so the lockfile
check code mistakenly thinks there's still an old postmaster.)  But
so far, the only thing worse than lockfiles is everything else :-(
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports
Next
From: Tom Lane
Date:
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports