From: | "Igor Kovalenko" <Igor(dot)Kovalenko(at)motorola(dot)com> |
---|---|
To: | "Matthew Kirkwood" <matthew(at)hairy(dot)beasts(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, "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 20:53:19 |
Message-ID: | 0f3301c1f60923ca70c30191@comm.mot.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Just a friendly reminder that it should be named pipe rather than UDS ;)
-- igor
> 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 | Igor Kovalenko | 2002-05-07 20:55:50 | Re: OK, lets talk portability. |
Previous Message | mlw | 2002-05-07 20:41:57 | Re: OK, lets talk portability. |