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

From Marc G. Fournier
Subject Re: HEADS UP: Win32/OS2/BeOS native ports
Date
Msg-id 20020506085309.X32524-100000@mail1.hub.org
Whole thread Raw
In response to Re: HEADS UP: Win32/OS2/BeOS native ports  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: HEADS UP: Win32/OS2/BeOS native ports  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, 4 May 2002, Tom Lane wrote:

> Matthew Kirkwood <matthew@hairy.beasts.org> writes:
> > On Fri, 3 May 2002, Tom Lane wrote:
> >> The SysV API lets us detect that case, but I don't see any
> >> equally good way to do it if we are using anonymous shared memory.
>
> > It's a hack (and has slight security implications), but you
> > could just allow the postgres backends to keep the listening
> > socket(s) open.
>
> Hmm.  That might be workable, but it feels shaky to me.  The problem
> is that you are using a lock based on port number to interlock a data
> directory --- and port number and data directory are independently
> variable parameters.  Consider
>     $ postmaster -D /my/dir &
>     -- dba thinks "oops, forgot to specify port"
>     $ kill -9 pm-pid                 # bad idea
>     $ postmaster -D /my/dir -p myport &
> Any backends started by the first postmaster will not be noticed by
> the second one, if the interlock is based on port number.
>
> We could get around this, of course: record the port number in the data
> directory lockfile, and test for existence of the old socket
> independently of trying to create a new one.  But it seems ugly.

How about a second, data directory based socket simply named something
like '.inuse', that is not port dependent?



pgsql-hackers by date:

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