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: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, Igor Kovalenko <Igor(dot)Kovalenko(at)motorola(dot)com>, mlw <markw(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports
Date: 2002-05-07 14:15:16
Message-ID: 23285.1020780916@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:
>> ... and we already do it. But it protects the port number, not
>> the data directory.

> If I understood him correctly, Marc was suggesting a further
> domain socket inside the data directory.

Right, and that would work because we would reference it as
$PGDATA/.socket --- exact, one-to-one correspondence between data
directory and interlock file. A TCP socket isn't going to have any
such direct connection to the data directory.

We could try to make such a connection (eg, pick a free port number at
random, and record the number in a lockfile in $PGDATA). But that will
suffer from a bunch of failure modes, starting with the same one that's
been biting us for PID interlocking: after a system restart, someone
else may hold the port number that we chose at random last time.

Basically, the reason that we want this interlock is because we are
going after five-nines kind of reliability. An interlock technology
that's not itself five-nines reliable isn't going to make things better.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-05-07 14:32:28 Re: OK, lets talk portability.
Previous Message Tom Lane 2002-05-07 14:04:49 Re: STILL LACKING: CVS tag for release 7.2.1