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 27984.1020530230@sss.pgh.pa.us
Whole thread Raw
In response to Re: HEADS UP: Win32/OS2/BeOS native ports  (Matthew Kirkwood <matthew@hairy.beasts.org>)
Responses Re: HEADS UP: Win32/OS2/BeOS native ports  ("Marc G. Fournier" <scrappy@hub.org>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: Re: Native Windows, Apache Portable Runtime
Next
From: Tom Lane
Date:
Subject: Re: Native Windows, Apache Portable Runtime