Re: HEADS UP: Win32/OS2/BeOS native ports

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org>
Cc: Igor Kovalenko <Igor(dot)Kovalenko(at)motorola(dot)com>, mlw <markw(at)mohawksoft(dot)com>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports
Date: 2002-05-04 16:37:10
Message-ID: 27984.1020530230@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-05-04 16:56:49 Re: Native Windows, Apache Portable Runtime
Previous Message mlw 2002-05-04 16:28:43 Re: Native Windows, Apache Portable Runtime