"Marc G. Fournier" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html