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.
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 silently
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. Those who
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 silently fail on
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 hard to
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
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 out a set
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
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]
---(end
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 be in
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 you can
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 leave
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
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
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
--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 we
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.
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 the
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 constrain
--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
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 should bind
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.
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 rationale? This
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 addresses
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 start? Either the
--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 admins
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
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:
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 handled
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
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 the
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 to IPv4
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 to IPv4 if
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: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 if
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 default?
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 for the user to
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 address family
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 issue.
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 must
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
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
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:
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
44 matches
Mail list logo
