Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > If we cleanly split the Postgres-specific code from the stuff that's
> > been imported from BIND, shouldn't it be easy to import new versions,
> > and thus get IPv6 support for free?
>
> IIRC, the issue was that we'd painfully hammered
Neil Conway <[EMAIL PROTECTED]> writes:
> If we cleanly split the Postgres-specific code from the stuff that's
> been imported from BIND, shouldn't it be easy to import new versions,
> and thus get IPv6 support for free?
IIRC, the issue was that we'd painfully hammered out a set of preferred
I/O b
That is _exactly_ how it has to be done.
---
Neil Conway wrote:
> On Mon, 2003-01-27 at 20:19, Bruce Momjian wrote:
> > I had someone on the IPv6 IRC channel interested, but haven't seen any
> > patch yet. It isn't that har
On Mon, 2003-01-27 at 20:19, Bruce Momjian wrote:
> I had someone on the IPv6 IRC channel interested, but haven't seen any
> patch yet. It isn't that hard to do.
If we cleanly split the Postgres-specific code from the stuff that's
been imported from BIND, shouldn't it be easy to import new versio
Christopher Kings-Lynne wrote:
> > > > However, the server log messages stating an IPv6 socket was
> > not made is
> > > > only printed if the binary supports IPv6. The message seems to be a
> > > > compromise between those who wanted a separate IPv6 GUC/flag and those
> > > > who wanted it to sil
> > > However, the server log messages stating an IPv6 socket was
> not made is
> > > only printed if the binary supports IPv6. The message seems to be a
> > > compromise between those who wanted a separate IPv6 GUC/flag and those
> > > who wanted it to silently fail on IPv6.
> >
> > I'm not sure.
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > However, the server log messages stating an IPv6 socket was not made is
> > only printed if the binary supports IPv6. The message seems to be a
> > compromise between those who wanted a separate IPv6 GUC/flag and those
> > who wanted it to sil
Bruce Momjian writes:
> However, the server log messages stating an IPv6 socket was not made is
> only printed if the binary supports IPv6. The message seems to be a
> compromise between those who wanted a separate IPv6 GUC/flag and those
> who wanted it to silently fail on IPv6.
I'm not sure.
OK, at your suggestion, IPv6 addresses will appear in pg_hba.conf, even
if we don't support IPv6.
However, the server log messages stating an IPv6 socket was not made is
only printed if the binary supports IPv6. The message seems to be a
compromise between those who wanted a separate IPv6 GUC/fl
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, you mentioned you want to put IPv6 addresses in pg_hba.conf even if
> > the OS doesn't support it. How do others feel about that.
>
> We do leave the "local" in there even if the OS doesn't support it.
Good point. I will have the IPv6 b
Bruce Momjian writes:
> OK, you mentioned you want to put IPv6 addresses in pg_hba.conf even if
> the OS doesn't support it. How do others feel about that.
We do leave the "local" in there even if the OS doesn't support it.
--
Peter Eisentraut [EMAIL PROTECTED]
---(
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > OK, Peter, to keep you and everyone happy, what changes are your
> > proposing to the existing code, if any. The only current behavior is
> > printing an IPv6 failure for IPv6-enabled backend in the server logs.
>
> Just bind to all addresses
Bruce Momjian writes:
> OK, Peter, to keep you and everyone happy, what changes are your
> proposing to the existing code, if any. The only current behavior is
> printing an IPv6 failure for IPv6-enabled backend in the server logs.
Just bind to all addresses you can find, IPv4 or IPv6. And leav
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Peter was the first to mention it. His reasoning was that if IPv6 was
> > working, but then stopped working, the admin would never know on startup
> > because of the IPv4 fallback.
>
> My view was that we should treat unix, ipv4, and ipv6 as
Bruce Momjian writes:
> Peter was the first to mention it. His reasoning was that if IPv6 was
> working, but then stopped working, the admin would never know on startup
> because of the IPv4 fallback.
My view was that we should treat unix, ipv4, and ipv6 as independent
address families each with
--On Tuesday, January 07, 2003 12:24:41 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane
<[EMAIL PROTECTED]> wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> We already do. The issue is what way should we give
Larry Rosenman wrote:
>
>
> --On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane <[EMAIL PROTECTED]>
> wrote:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> We already do. The issue is what way should we give admins to _fail_ if
> >> IPv6 doesn't start.
> >
> > What is "IPv6 doesn't st
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We already do. The issue is what way should we give admins to _fail_ if
> > IPv6 doesn't start.
>
> What is "IPv6 doesn't start"? Either the machine has IPv6 addresses,
> or it doesn't. It is not our job to notify the DBA what the
--On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
We already do. The issue is what way should we give admins to _fail_ if
IPv6 doesn't start.
What is "IPv6 doesn't start"? Either the machine has IPv6 addresses,
or it
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The issue was that folks didn't like silent fallback to just IPv4 if the
> > code supported IPv6 but it didn't bind to IPv6 for some reason, e.g.
> > kernel doesn't have IPv6 enabled.
>
> Who didn't like it, and what was their rationa
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We already do. The issue is what way should we give admins to _fail_ if
> IPv6 doesn't start.
What is "IPv6 doesn't start"? Either the machine has IPv6 addresses,
or it doesn't. It is not our job to notify the DBA what the addresses
on his machine are
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The issue was that folks didn't like silent fallback to just IPv4 if the
> code supported IPv6 but it didn't bind to IPv6 for some reason, e.g.
> kernel doesn't have IPv6 enabled.
Who didn't like it, and what was their rationale? This seems to me to
be
Tom Lane wrote:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Please make sure that you can handle the situation of a IPv6 API, but no
> > IPv6 stack. (E.G. UnixWare up to at least 7.1.3).
>
> Certainly. But that is just an autoconfiguration problem. If a v6 IP
> address is available, we sh
--On Tuesday, January 07, 2003 12:07:05 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
Please make sure that you can handle the situation of a IPv6 API, but no
IPv6 stack. (E.G. UnixWare up to at least 7.1.3).
Certainly. But that is just an autoconfigu
Larry Rosenman wrote:
> > No one has offered any scenario in which it's important to bind to only
> > v4 or only v6 addresses when both are present. In the absence of a
> > compelling argument why that would be useful, I do not see why we're
> > worrying. My own thought is that if I wanted to con
Tom Lane wrote:
> Rocco Altier <[EMAIL PROTECTED]> writes:
> > Another idea is to have the -i take an optional argument. Something where
> > -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only
> > v6.
>
> I don't see why we need any such thing. The current behavior of th
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Please make sure that you can handle the situation of a IPv6 API, but no
> IPv6 stack. (E.G. UnixWare up to at least 7.1.3).
Certainly. But that is just an autoconfiguration problem. If a v6 IP
address is available, we should bind to it.
--On Tuesday, January 07, 2003 11:51:44 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Rocco Altier <[EMAIL PROTECTED]> writes:
Another idea is to have the -i take an optional argument. Something
where -i means bind to both v4 and v6, and -i4 means to only v4, and -i6
to only v6.
I don't see why
Rocco Altier <[EMAIL PROTECTED]> writes:
> Another idea is to have the -i take an optional argument. Something where
> -i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only
> v6.
I don't see why we need any such thing. The current behavior of the
postmaster (assuming -i or
Another idea is to have the -i take an optional argument. Something where
-i means bind to both v4 and v6, and -i4 means to only v4, and -i6 to only
v6.
I am guessing that most people will want to bind to both when they
just specify -i, which is what is usually suggested when they want to get
t
You mean ship with only IPv4 enabled, but not IPv6. (Of course, both
are enabled in the binary.) But then what does -i do? We currently
tell people to use -i. Do we need another postgresql.conf option that
says, "If tcpip_socket is enabled, enable IPv6 too"? But that doesn't
work if you want
OK, what do we ship as a default?
---
Nigel Kukard wrote:
> Sorry i'm not subscribed to hackers, guess i must get soon!
>
>
> Anyway what i think should happen is follows, if in the configuration file
> we specify that it
On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> The issue is that right now, there isn't any special IPv6 enabling,
> except for lines in pg_hba.conf. I think it is fine to add some
> enabling, but we then have an additional user interface is
Greg Copeland wrote:
> > > > Yes, it listens on both. The original author, Nigel, tested in using
> > > > both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem
> > > > to indicate that too. What I am not sure how to do is say _only_ IPv4.
> > >
> > > Wouldn't you just use an IPv4
On Mon, 2003-01-06 at 16:17, Bruce Momjian wrote:
> Greg Copeland wrote:
> > On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote:
> > > Greg Copeland wrote:
> > > > > It appears right at the top because creating the socket is the first
> > > > > thing it does. A good question is once we have a way fo
Greg Copeland wrote:
> On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote:
> > Greg Copeland wrote:
> > > > It appears right at the top because creating the socket is the first
> > > > thing it does. A good question is once we have a way for the user to
> > > > control IPv4/6, what do we ship as a d
On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote:
> Greg Copeland wrote:
> > > It appears right at the top because creating the socket is the first
> > > thing it does. A good question is once we have a way for the user to
> > > control IPv4/6, what do we ship as a default? IPv4-only? Both, and
Greg Copeland wrote:
> > It appears right at the top because creating the socket is the first
> > thing it does. A good question is once we have a way for the user to
> > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if
> > both, do we fail on a kernel that doesn't have IPv6
On Mon, 2003-01-06 at 15:43, Bruce Momjian wrote:
> Greg Copeland wrote:
> > On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote:
> > > (2) A socket type is explicitly enabled for the server to use, and if
> > > creation fails, server startup fails. It seems that the current code
> > > falls back
Greg Copeland wrote:
> On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote:
> > (2) A socket type is explicitly enabled for the server to use, and if
> > creation fails, server startup fails. It seems that the current code
> > falls back to IPv4 if IPv6 fails.
>
> IIRC, it allows it to fall back
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Patch applied. I added a small mention of IPv6 addresses to the
> > pg_hba.conf documentation. Not sure where else to mention it.
>
> Can this patch please be cleaned up so the code doesn't contain an #ifdef
> on every other line?
I posted
On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote:
> (2) A socket type is explicitly enabled for the server to use, and if
> creation fails, server startup fails. It seems that the current code
> falls back to IPv4 if IPv6 fails.
IIRC, it allows it to fall back to IPv4 in case it's compiled for
Bruce Momjian writes:
> Patch applied. I added a small mention of IPv6 addresses to the
> pg_hba.conf documentation. Not sure where else to mention it.
Can this patch please be cleaned up so the code doesn't contain an #ifdef
on every other line?
I would also like to discuss how IPv6 is handle
Patch applied. I added a small mention of IPv6 addresses to the
pg_hba.conf documentation. Not sure where else to mention it.
---
Bruce Momjian wrote:
> I have been working on a patch to implement IPv6 connections. A work
I have been working on a patch to implement IPv6 connections. A working
patch was supplied by Nigel Kukard about two weeks ago, and I have been
improving it. The original patch assumed the system has IPv6 functions,
like getaddrinfo(), so the major work was patching it into our existing
code that
I didn't read my email this weekend, so I am sorry to be late getting
back to you on this.
First, let me say I am excited about this patch. Several people have
asked for IPv6 support, but you are the first person to actually submit
a patch for it.
I want to comment on the patch a bit because IP
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am pretty sure it is going to fail if your machine isn't INET6 aware,
> which may be many.
That's definitely not gonna do :-(
regards, tom lane
---(end of broadcast)---
TIP 1: su
I now have the INETv6 patch working using IPv4 on my machine, and I
don't have IPv6 enabled in my kernel. Tomorrow, I will review the
entire patch for portability issues, then post it so others can test it.
I am pretty sure it is going to fail if your machine isn't INET6 aware,
which may be many.
The INETv6 patch was rejected because of this report, and an error on
postmaster startup from BSD/OS:
LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor
servname provided, or not known
Please submit a new patch that addresses these issues. I can work with
you to
49 matches
Mail list logo
