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
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 |