
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 _only_ IPv6.

The big problem is it doesn't mix with tcpip_socket and -i very well.  I
am not saying I have a better idea, I am just looking for something
clearer.  Perhaps we need a separate flag/postgresql.conf option for
IPv6 so they can be controlled separately.  Have we figured out how to
listen on IPv6 only?

---------------------------------------------------------------------------

Nigel Kukard wrote:
> 
> IPV4 only should be shipped by default, but disabled as it is at present.
> 
> 
> On Tue, 7 Jan 2003, Bruce Momjian wrote:
> 
> > 
> > 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 bind to both ie. tcpip_socket = true, the server
> > > should check if first its compiled to support ipv6 (or skip this if we use
> > > #ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it
> > > must try to bind to both. Ok thats the first case, the second case is if
> > > we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6
> > > and if there is no ipv4 support on the box it should fail, not fallback.
> > > And finally the third case, if we specify   tcpip_socket = 6, we should
> > > again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we
> > > cannot bind to the specific interface we should fail.
> > > 
> > > Thats my opinion ;)
> > > 
> > > 
> > > -Nigel
> > > 
> > > 
> > > 
> > > On 6 Jan 2003, Robert Treat wrote:
> > > 
> > > > 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.  One idea
> > > > > I had was to change tcpip_socket from true/false to true/false/4/6 so
> > > > > you can specify if you want none(false)/4/6/both(true).  The original
> > > > > patch author wants this functionality too, so there clearly is a need
> > > > > for this.  This doesn't play nice with the -i flag, however.
> > > > >
> > > > 
> > > > Would there a downside to specifying both (enabling ipv6) on a machine
> > > > that doesn't support it? If not I'd suggest making -i equivalent to
> > > > tcp_ip_socket = true. I don't think it's too much to ask people to use
> > > > the preferred method to obtain maximum functionality.
> > > >  
> > > > > Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6
> > > > > isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true,
> > > > > but when run, opening an IPV6 server fails and I fall back to IPv4 ---
> > > > > just throwing that out as a data point.  What would be our default as
> > > > > shipped?
> > > > 
> > > > If there is no downside to allowing both, probably both. If there is a
> > > > downside then ipv4, since it much more likely to be the default on OS's
> > > > for the next release or two.
> > > > 
> > > > Robert Treat
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > -- 
> > > 
> > > 
> > > Nigel Kukard  (Chief Executive Officer)
> > > Lando Technologies Africa (Pty) Ltd
> > > nigel@lando.co.za   www.lando.co.za
> > > Tel: 083 399 5822  Fax: 086 1100036
> > > Hoheisen Park Bellville,  Cape Town
> > > National  Internet Service Provider
> > > 
> > > 
> > >   The best language to use is the language that was designed for
> > >          what you want to use it for - 1997
> > > 
> > > 
> > > =====================================================================
> > > 
> > > Disclaimer
> > > ----------
> > > The contents of this message and any attachments are intended 
> > > solely for the addressee's use and may be legally privileged and/or 
> > > confidential information. This message may not be retained, 
> > > distributed, copied or used if you are not he addressee of this 
> > > message. If this message was sent to you in error, please notify 
> > > the sender immediately by reply e-mail and then destroy the message 
> > > and any copies thereof.
> > > 
> > > Opinions, conclusions and other information in this message may be 
> > > personal to the sender and is not that of Lando Technologies Africa 
> > > or any of it's subsideries, associated companies or principals and 
> > > is therefore not endorsed by any of the Lando groups of companies. 
> > > Due to e-maill communication being insecure, Lando groups of 
> > > companies do not guarantee confidentiality, security, accuracy or  
> > > performance of the e-mail. Any liability for viruses is excluded 
> > > to the fullest extent.
> > > 
> > > 
> > 
> > 
> 
> -- 
> 
> 
> Nigel Kukard  (Chief Executive Officer)
> Lando Technologies Africa (Pty) Ltd
> nigel@lando.co.za   www.lando.co.za
> Tel: 083 399 5822  Fax: 086 1100036
> Hoheisen Park Bellville,  Cape Town
> National  Internet Service Provider
> 
> 
>   The best language to use is the language that was designed for
>          what you want to use it for - 1997
> 
> 
> =====================================================================
> 
> Disclaimer
> ----------
> The contents of this message and any attachments are intended 
> solely for the addressee's use and may be legally privileged and/or 
> confidential information. This message may not be retained, 
> distributed, copied or used if you are not he addressee of this 
> message. If this message was sent to you in error, please notify 
> the sender immediately by reply e-mail and then destroy the message 
> and any copies thereof.
> 
> Opinions, conclusions and other information in this message may be 
> personal to the sender and is not that of Lando Technologies Africa 
> or any of it's subsideries, associated companies or principals and 
> is therefore not endorsed by any of the Lando groups of companies. 
> Due to e-maill communication being insecure, Lando groups of 
> companies do not guarantee confidentiality, security, accuracy or  
> performance of the e-mail. Any liability for viruses is excluded 
> to the fullest extent.
> 
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 7 Jan 2003 11:17:01 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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
the box up and running.

If they want do something fancy, like only bind to v6, then they will read
the docs and see that they can do that with something like -i6.

	-rocco

On Tue, 7 Jan 2003, Bruce Momjian wrote:

> 
> 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 _only_ IPv6.
> 
> The big problem is it doesn't mix with tcpip_socket and -i very well.  I
> am not saying I have a better idea, I am just looking for something
> clearer.  Perhaps we need a separate flag/postgresql.conf option for
> IPv6 so they can be controlled separately.  Have we figured out how to
> listen on IPv6 only?
> 
> ---------------------------------------------------------------------------
> 
> Nigel Kukard wrote:
> > 
> > IPV4 only should be shipped by default, but disabled as it is at present.
> > 
> > 
> > On Tue, 7 Jan 2003, Bruce Momjian wrote:
> > 
> > > 
> > > 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 bind to both ie. tcpip_socket = true, the server
> > > > should check if first its compiled to support ipv6 (or skip this if we use
> > > > #ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it
> > > > must try to bind to both. Ok thats the first case, the second case is if
> > > > we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6
> > > > and if there is no ipv4 support on the box it should fail, not fallback.
> > > > And finally the third case, if we specify   tcpip_socket = 6, we should
> > > > again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we
> > > > cannot bind to the specific interface we should fail.
> > > > 
> > > > Thats my opinion ;)
> > > > 
> > > > 
> > > > -Nigel
> > > > 
> > > > 
> > > > 
> > > > On 6 Jan 2003, Robert Treat wrote:
> > > > 
> > > > > 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.  One idea
> > > > > > I had was to change tcpip_socket from true/false to true/false/4/6 so
> > > > > > you can specify if you want none(false)/4/6/both(true).  The original
> > > > > > patch author wants this functionality too, so there clearly is a need
> > > > > > for this.  This doesn't play nice with the -i flag, however.
> > > > > >
> > > > > 
> > > > > Would there a downside to specifying both (enabling ipv6) on a machine
> > > > > that doesn't support it? If not I'd suggest making -i equivalent to
> > > > > tcp_ip_socket = true. I don't think it's too much to ask people to use
> > > > > the preferred method to obtain maximum functionality.
> > > > >  
> > > > > > Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6
> > > > > > isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true,
> > > > > > but when run, opening an IPV6 server fails and I fall back to IPv4 ---
> > > > > > just throwing that out as a data point.  What would be our default as
> > > > > > shipped?
> > > > > 
> > > > > If there is no downside to allowing both, probably both. If there is a
> > > > > downside then ipv4, since it much more likely to be the default on OS's
> > > > > for the next release or two.
> > > > > 
> > > > > Robert Treat
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > -- 
> > > > 
> > > > 
> > > > Nigel Kukard  (Chief Executive Officer)
> > > > Lando Technologies Africa (Pty) Ltd
> > > > nigel@lando.co.za   www.lando.co.za
> > > > Tel: 083 399 5822  Fax: 086 1100036
> > > > Hoheisen Park Bellville,  Cape Town
> > > > National  Internet Service Provider
> > > > 
> > > > 
> > > >   The best language to use is the language that was designed for
> > > >          what you want to use it for - 1997
> > > > 
> > > > 
> > > > =====================================================================
> > > > 
> > > > Disclaimer
> > > > ----------
> > > > The contents of this message and any attachments are intended 
> > > > solely for the addressee's use and may be legally privileged and/or 
> > > > confidential information. This message may not be retained, 
> > > > distributed, copied or used if you are not he addressee of this 
> > > > message. If this message was sent to you in error, please notify 
> > > > the sender immediately by reply e-mail and then destroy the message 
> > > > and any copies thereof.
> > > > 
> > > > Opinions, conclusions and other information in this message may be 
> > > > personal to the sender and is not that of Lando Technologies Africa 
> > > > or any of it's subsideries, associated companies or principals and 
> > > > is therefore not endorsed by any of the Lando groups of companies. 
> > > > Due to e-maill communication being insecure, Lando groups of 
> > > > companies do not guarantee confidentiality, security, accuracy or  
> > > > performance of the e-mail. Any liability for viruses is excluded 
> > > > to the fullest extent.
> > > > 
> > > > 
> > > 
> > > 
> > 
> > -- 
> > 
> > 
> > Nigel Kukard  (Chief Executive Officer)
> > Lando Technologies Africa (Pty) Ltd
> > nigel@lando.co.za   www.lando.co.za
> > Tel: 083 399 5822  Fax: 086 1100036
> > Hoheisen Park Bellville,  Cape Town
> > National  Internet Service Provider
> > 
> > 
> >   The best language to use is the language that was designed for
> >          what you want to use it for - 1997
> > 
> > 
> > =====================================================================
> > 
> > Disclaimer
> > ----------
> > The contents of this message and any attachments are intended 
> > solely for the addressee's use and may be legally privileged and/or 
> > confidential information. This message may not be retained, 
> > distributed, copied or used if you are not he addressee of this 
> > message. If this message was sent to you in error, please notify 
> > the sender immediately by reply e-mail and then destroy the message 
> > and any copies thereof.
> > 
> > Opinions, conclusions and other information in this message may be 
> > personal to the sender and is not that of Lando Technologies Africa 
> > or any of it's subsideries, associated companies or principals and 
> > is therefore not endorsed by any of the Lando groups of companies. 
> > Due to e-maill communication being insecure, Lando groups of 
> > companies do not guarantee confidentiality, security, accuracy or  
> > performance of the e-mail. Any liability for viruses is excluded 
> > to the fullest extent.
> > 
> > 
> 
> -- 
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

Tue, 7 Jan 2003 11:35:20 -0500 (EST)
Rocco Altier <RoccoA@Routescape.com>
Re: IPv6 patch
Rocco Altier <RoccoA@Routescape.com> 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 tcpip_socket is set) is:

1. By default: bind to all IPs on the machine.

2. If virtual_host is set: bind only to that one IP.

It seems to me that in a machine with both v4 and v6 IP addresses, the
natural extension is that the default behavior is to bind to all of
them, or if virtual_host is set then bind to only that one, be it v4 or
v6.  (Does the existing patch work with virtual_host identifying a v6
IP?  If not, that's certainly a bug.)

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 PG to bind
to a subset of a machine's addresses, the extension I'd want is to allow
virtual_host to contain a list of names or IP addresses --- of either
version.  Basing it on v4 versus v6 has no payback that I can see.

			regards, tom lane

Tue, 07 Jan 2003 11:51:44 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: IPv6 patch 


--On Tuesday, January 07, 2003 11:51:44 -0500 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Rocco Altier <RoccoA@Routescape.com> 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 tcpip_socket is set) is:
>
> 1. By default: bind to all IPs on the machine.
>
> 2. If virtual_host is set: bind only to that one IP.
>
> It seems to me that in a machine with both v4 and v6 IP addresses, the
> natural extension is that the default behavior is to bind to all of
> them, or if virtual_host is set then bind to only that one, be it v4 or
> v6.  (Does the existing patch work with virtual_host identifying a v6
> IP?  If not, that's certainly a bug.)
>
> 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 PG to bind
> to a subset of a machine's addresses, the extension I'd want is to allow
> virtual_host to contain a list of names or IP addresses --- of either
> version.  Basing it on v4 versus v6 has no payback that I can see.
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).


>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749




Tue, 07 Jan 2003 10:55:58 -0600
Larry Rosenman <ler@lerctr.org>
Re: IPv6 patch 
Larry Rosenman <ler@lerctr.org> 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.

			regards, tom lane

Tue, 07 Jan 2003 12:07:05 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: IPv6 patch 
Tom Lane wrote:
> Rocco Altier <RoccoA@Routescape.com> 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 tcpip_socket is set) is:
> 
> 1. By default: bind to all IPs on the machine.
> 
> 2. If virtual_host is set: bind only to that one IP.
> 
> It seems to me that in a machine with both v4 and v6 IP addresses, the
> natural extension is that the default behavior is to bind to all of
> them, or if virtual_host is set then bind to only that one, be it v4 or
> v6.  (Does the existing patch work with virtual_host identifying a v6
> IP?  If not, that's certainly a bug.)
> 
> 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 PG to bind
> to a subset of a machine's addresses, the extension I'd want is to allow
> virtual_host to contain a list of names or IP addresses --- of either
> version.  Basing it on v4 versus v6 has no payback that I can see.

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.  Right now it puts a message in the
server logs, but others wanted some specific way to enable IPv6 and fail
if it didn't work.  They want something that says "I want IPv6 and I
don't want to start if it doesn't start."  Right now if we do -i, and
tcpip doesn't start, be bomb out.  They want that for IPv6, and the
tricky part is we can't enable that by default because many systems have
the API but no kernel support.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 7 Jan 2003 12:10:02 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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 PG to bind
> > to a subset of a machine's addresses, the extension I'd want is to allow
> > virtual_host to contain a list of names or IP addresses --- of either
> > version.  Basing it on v4 versus v6 has no payback that I can see.
>
> 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).

Already done.  My BSD/OS is that way in the default kernel configuration
too.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 7 Jan 2003 12:10:38 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
Tom Lane wrote:
> Larry Rosenman <ler@lerctr.org> 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.

We already do.  The issue is what way should we give admins to _fail_ if
IPv6 doesn't start.  Maybe just a postgresql.conf setting,
"exit_on_ipv6_failure" or something like that.  It unlinks the param to
the -i/tcpip_socket functionality.  However, it doesn't give us a way to
do IPv4 only if the server supports IPv6 too, or to do IPv6 only.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 7 Jan 2003 12:12:20 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch


--On Tuesday, January 07, 2003 12:07:05 -0500 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Larry Rosenman <ler@lerctr.org> 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.
Agreed, but I wanted to at least make sure the issue was known.  The Apache 
guys
had to put a special check in for UnixWare since we die in a different way. 
I can show
you the patch if y'all want.


>
> 			regards, tom lane



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749




Tue, 07 Jan 2003 11:12:55 -0600
Larry Rosenman <ler@lerctr.org>
Re: IPv6 patch 
Bruce Momjian <pgman@candle.pha.pa.us> 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 equivalent to expecting Postgres to list out every IP address in the
world *except* the ones it was able to bind to.  That's silly.

If the system does not support IPv6, there will be no v6 address
available to bind to.  It is not going to startle anyone when we do
not bind to an IPv6 address on such a machine.

> Right now it puts a message in the
> server logs, but others wanted some specific way to enable IPv6 and fail
> if it didn't work.

Pure noise, and a useless "feature".

			regards, tom lane

Tue, 07 Jan 2003 12:19:03 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: IPv6 patch 
Bruce Momjian <pgman@candle.pha.pa.us> 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.

			regards, tom lane

Tue, 07 Jan 2003 12:20:31 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: IPv6 patch 
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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

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.

> be equivalent to expecting Postgres to list out every IP address in the
> world *except* the ones it was able to bind to.  That's silly.
> 
> If the system does not support IPv6, there will be no v6 address
> available to bind to.  It is not going to startle anyone when we do
> not bind to an IPv6 address on such a machine.
> 
> > Right now it puts a message in the
> > server logs, but others wanted some specific way to enable IPv6 and fail
> > if it didn't work.
> 
> Pure noise, and a useless "feature".

Again, that info is for the admin so they have some feedback that we
aren't using IPv6, even though IPv6 addresses appear in pg_hba.conf
(only because we had the IPv6 API).

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 7 Jan 2003 12:21:28 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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.

You can fight it out with Peter.  I have no problem silently falling
back to IPv4 if people are happy with that.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 7 Jan 2003 12:22:27 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch


--On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane <tgl@sss.pgh.pa.us> 
wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> 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.
In the UnixWare case, you can't even find out if there is an IPv6 address, 
and
the API returns a wierd error, IIRC.


>
> 			regards, tom lane



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749




Tue, 07 Jan 2003 11:23:45 -0600
Larry Rosenman <ler@lerctr.org>
Re: IPv6 patch 
Larry Rosenman wrote:
> 
> 
> --On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane <tgl@sss.pgh.pa.us> 
> wrote:
> 
> > Bruce Momjian <pgman@candle.pha.pa.us> 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.
> In the UnixWare case, you can't even find out if there is an IPv6 address, 
> and
> the API returns a wierd error, IIRC.

I don't think we care about how IPv6 fails in our code --- we just fall
back to IPv4.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 7 Jan 2003 12:24:41 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch


--On Tuesday, January 07, 2003 12:24:41 -0500 Bruce Momjian 
<pgman@candle.pha.pa.us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Tuesday, January 07, 2003 12:20:31 -0500 Tom Lane
>> <tgl@sss.pgh.pa.us>  wrote:
>>
>> > Bruce Momjian <pgman@candle.pha.pa.us> 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.
>> In the UnixWare case, you can't even find out if there is an IPv6
>> address,  and
>> the API returns a wierd error, IIRC.
>
> I don't think we care about how IPv6 fails in our code --- we just fall
> back to IPv4.
Ok, just checking.  IIRC, apache2 refused to start BECAUSE of the this 
return
prior to Jeff Trawick's change of the check.

If someone wants to try it, I can generate an account.  (Peter E. already 
has one).

the machine is finally running a released OS again :-).

LER



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749




Tue, 07 Jan 2003 11:27:19 -0600
Larry Rosenman <ler@lerctr.org>
Re: IPv6 patch
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 their own on/off switch (except that unix
doesn't have an off switch).  Tom's view is that we should treat ipv4 and
ipv6 as effectively one address family.  That makes sense, too, and it is
probably more with the spirit of IPv6.

-- 
Peter Eisentraut   peter_e@gmx.net


Tue, 7 Jan 2003 21:58:33 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: IPv6 patch
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 independent
> address families each with their own on/off switch (except that unix
> doesn't have an off switch).  Tom's view is that we should treat ipv4 and
> ipv6 as effectively one address family.  That makes sense, too, and it is
> probably more with the spirit of IPv6.

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.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 7 Jan 2003 16:09:34 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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
pg_hba.conf alone.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 9 Jan 2003 22:50:44 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: IPv6 patch
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 find, IPv4 or IPv6.  And leave
> pg_hba.conf alone.

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.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Thu, 9 Jan 2003 16:53:54 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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 there all the time.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fri, 17 Jan 2003 18:03:00 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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   peter_e@gmx.net


Sat, 18 Jan 2003 00:06:06 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: IPv6 patch
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/flag and those
who wanted it to silently fail on IPv6.

---------------------------------------------------------------------------

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.
> 
> -- 
> Peter Eisentraut   peter_e@gmx.net
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: src/backend/Makefile
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/Makefile,v
retrieving revision 1.92
diff -c -c -r1.92 Makefile
*** src/backend/Makefile	7 Jan 2003 15:12:17 -0000	1.92
--- src/backend/Makefile	26 Jan 2003 01:17:32 -0000
***************
*** 132,145 ****
  endif
  endif
  	$(MAKE) -C catalog install-data
- ifdef HAVE_IPV6
  	$(INSTALL_DATA) $(srcdir)/libpq/pg_hba.conf.sample $(DESTDIR)$(datadir)/pg_hba.conf.sample
- else
- 	grep -v '^host.*::1.*ffff:ffff:ffff:ffff:ffff:ffff' \
- 		$(srcdir)/libpq/pg_hba.conf.sample \
- 		> $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6
- 	$(INSTALL_DATA) $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6 $(DESTDIR)$(datadir)/pg_hba.conf.sample
- endif
  	$(INSTALL_DATA) $(srcdir)/libpq/pg_service.conf.sample $(DESTDIR)$(datadir)/pg_service.conf.sample
  	$(INSTALL_DATA) $(srcdir)/libpq/pg_ident.conf.sample $(DESTDIR)$(datadir)/pg_ident.conf.sample
  	$(INSTALL_DATA) $(srcdir)/utils/misc/postgresql.conf.sample $(DESTDIR)$(datadir)/postgresql.conf.sample
--- 132,138 ----
***************
*** 191,199 ****
  	rm -f postgres$(X) $(POSTGRES_IMP) \
  		$(top_srcdir)/src/include/parser/parse.h \
  		$(top_builddir)/src/include/utils/fmgroids.h
- ifndef HAVE_IPV6
- 	rm -f $(srcdir)/libpq/pg_hba.conf.sample.no_ipv6
- endif
  ifeq ($(PORTNAME), win)
  	rm -f postgres.dll postgres.def libpostgres.a
  endif
--- 184,189 ----
Sat, 25 Jan 2003 20:21:05 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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.  Those who wanted silence don't get any silence and those
who wanted a configurable hard failure get neither the configurability nor
any failure.

-- 
Peter Eisentraut   peter_e@gmx.net


Mon, 27 Jan 2003 22:09:18 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: IPv6 patch
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 fail on IPv6.
> 
> I'm not sure.  Those who wanted silence don't get any silence and those
> who wanted a configurable hard failure get neither the configurability nor
> any failure.

That is the compromise.  Neither gets what they want, but the final
solution is closer to each.  This is probably the best we can do.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 27 Jan 2003 16:32:14 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
> > > 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 wanted silence don't get any silence and those
> > who wanted a configurable hard failure get neither the
> configurability nor
> > any failure.
>
> That is the compromise.  Neither gets what they want, but the final
> solution is closer to each.  This is probably the best we can do.

BTW guys, there was strong demand at Linux.conf.au asking for the 'inet'
type to support IPv6 addresses.  I've been looking at it a bit, but I'll
have to interleave it with my work on phpPgAdmin 3 (which rocks BTW :) ).

Chris


Tue, 28 Jan 2003 09:18:14 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: IPv6 patch
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 IPv6.
> > >
> > > I'm not sure.  Those who wanted silence don't get any silence and those
> > > who wanted a configurable hard failure get neither the
> > configurability nor
> > > any failure.
> >
> > That is the compromise.  Neither gets what they want, but the final
> > solution is closer to each.  This is probably the best we can do.
> 
> BTW guys, there was strong demand at Linux.conf.au asking for the 'inet'
> type to support IPv6 addresses.  I've been looking at it a bit, but I'll
> have to interleave it with my work on phpPgAdmin 3 (which rocks BTW :) ).

I had someone on the IPv6 IRC channel interested, but haven't seen any
patch yet.  It isn't that hard to do.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 27 Jan 2003 20:19:35 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
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 versions,
and thus get IPv6 support for free?

Or at least, that's what I vaguely recall Paul Vixie saying on
pgsql-patches a while ago:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=200202221828.g1MISX102055%40candle.pha.pa.us&rnum=2&prev=/groups%3Fq%3Dpaul%2Bvixie%2Bgroup:comp.databases.postgresql.patches%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D200202221828.g1MISX102055%2540candle.pha.pa.us%26rnum%3D2

Cheers,

Neil
-- 
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC




27 Jan 2003 21:06:11 -0500
Neil Conway <neilc@samurai.com>
Re: IPv6 patch

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 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 versions,
> and thus get IPv6 support for free?
> 
> Or at least, that's what I vaguely recall Paul Vixie saying on
> pgsql-patches a while ago:
> 
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=200202221828.g1MISX102055%40candle.pha.pa.us&rnum=2&prev=/groups%3Fq%3Dpaul%2Bvixie%2Bgroup:comp.databases.postgresql.patches%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D200202221828.g1MISX102055%2540candle.pha.pa.us%26rnum%3D2
> 
> Cheers,
> 
> Neil
> -- 
> Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
> 
> 
> 
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 27 Jan 2003 21:07:34 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch
Neil Conway <neilc@samurai.com> 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 behaviors for the inet and cidr datatypes, and then hacked up the
code we'd imported from BIND to make it happen.  Paul Vixie sent in a
patch that replaced the imported code with v6-aware BIND code ---
thereby reverting those painfully-agreed-to patches.  So it got
rejected.

I have no problem with restructuring our I/O behavior as wrappers around
the pristine BIND routines; although privately I doubt it's worth the
trouble.  The really interesting part of upgrading to v6 inet support is
going to be obtaining a consensus on how our current I/O behaviors should
translate to v6 addresses.  Once we have that, I suspect that slash-and-
burn mods on the BIND code will again be the way to go ;-).  It's not
like v6 is going to be replaced in the foreseeable future.

			regards, tom lane

Mon, 27 Jan 2003 22:08:49 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: IPv6 patch 
Tom Lane wrote:
> Neil Conway <neilc@samurai.com> 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 behaviors for the inet and cidr datatypes, and then hacked up the
> code we'd imported from BIND to make it happen.  Paul Vixie sent in a
> patch that replaced the imported code with v6-aware BIND code ---
> thereby reverting those painfully-agreed-to patches.  So it got
> rejected.
> 
> I have no problem with restructuring our I/O behavior as wrappers around
> the pristine BIND routines; although privately I doubt it's worth the
> trouble.  The really interesting part of upgrading to v6 inet support is
> going to be obtaining a consensus on how our current I/O behaviors should
> translate to v6 addresses.  Once we have that, I suspect that slash-and-
> burn mods on the BIND code will again be the way to go ;-).  It's not
> like v6 is going to be replaced in the foreseeable future.

Yes, we need to keep merge the changes we made to the original IPv4 code
into IPv6.  IPv6 seems to be maturing a little so if we can keep the
bind stuff pretty similar and just call it, that would be nice too. 
Seems someone has to do the legwork and see what is involved.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 27 Jan 2003 22:11:39 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: IPv6 patch