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

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: 0f3301c1f609$3923ca70$22c30191@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
>

In response to

Responses

Browse pgsql-hackers by date

  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.