* Mike Mascari <mascarm@mascari.com> [000708 05:55] wrote:
> Alfred Perlstein wrote:
> >
> > * Jan Wieck <JanWieck@t-online.de> [000708 05:47] wrote:
> > > Tom Lane wrote:
> > > >
> > > > Bruce and I were just talking by phone about this, and we realized that
> > > > there is a completely different approach to making that decision: if you
> > > > want to know whether there's an old postmaster connected to a socket
> > > > file, try to connect to the old postmaster! In other words, pretend to
> > > > be a client and see if your connection attempt is answered. (You don't
> > > > have to try to log in, just see if you get a connection.) This might
> > > > also answer Peter's concern about socket files that belong to
> > > > non-Postgres programs, although I doubt that's really a big issue.
> > > >
> > > > There are some potential pitfalls here, like what if the old postmaster
> > > > is there but overloaded? But on the whole it seems like it might be
> > > > a cleaner answer than fooling around with lockfiles, and certainly safer
> > > > than relying on fcntl(SETLK) to work on a socket file. Comments anyone?
> > >
> > > Like it.
> >
> > my $pgsocket = "/tmp/.s.PGSQL.5432";
> >
> > # try to connect to the postmaster
> > socket(SOCK, PF_UNIX, SOCK_STREAM, 0)
> > or die "unable to create unix domain socket: $!";
> >
> > connect(SOCK, sockaddr_un($pgsocket))
> > and errexit("postmaster is running you must shut it down");
> >
> > oh yeah... :)
> >
> > -Alfred
>
> I don't get this. Isn't there a race condition here?
>
> Just curious,
Sure but it's handled, if there's a postmaster starting at this
exact instant, however since the script just runs postmaster
afterwards the conflict will make postmaster abort and I'll get an
error return from my invocation of postmaster.
-Alfred
