Thread: Linux.conf.au 2003 Report
Linux.conf.au Report -------------------- The Linux.conf.au is an international Linux/Open Source event that attracts lots of international speakers. Total conf attendance was around 360, maybe even 400 I think. Gavin Sherry was speaking at this particular conf, and I attended as a hobbyist. PostgreSQL got a reasonable amount of attention, particularly since there were no representatives from other database products there. Some pics of our PostgreSQL BOF and the Perth Bell Tower: http://www.zip.com.au/~swm/lca2003 (Gavin is the beardy looking dude 3rd from the left :) I'm taking the photo.) These are the main questions we where asked, or features that were requested: * Replication, replication, replication! - We told them that there are a few solutions, none of them are particularly great. Gavin got all sorts of ideas about log shipping. * IPV6 data types - Apparently there are some ISPs in some countries that have started to bill people for IPV6 bandwidth, and the lack of IPV6 address types is hurting them. * Collisions in auto-generated names. - The standard table modification tactic (that I also use) or renaming table to *_old and creating new one breaks because the primary key of the new table is assigned the same name as the PK of the old, causing CREATE TABLE to fail. This is really annoying. I think that auto-generated names should never collide. * Problem: person has large database with 4 or 5 humungous tables that they aren't interested in backing up. However, they want to back up the rest. - I suggested that if pg_dump could dump individual schemas, then they could move their 'don't backup' tables to another schema, and just dump the other one. We found out all sorts of interesting places that PostgreSQL is being used: a large Australian Telco, several restaurants in the Perth area, the Debian inventory system and the Katie revision control system. It is also being evaluated for process control analysis at a steel plant. Maybe we should chase some people for case studies? Chris Kings-Lynne
On Wed, 2003-01-29 at 21:49, Christopher Kings-Lynne wrote: > * IPV6 data types Looks like this will be in 7.4, in one form or another. > - The standard table modification tactic (that I also use) or renaming table > to *_old and creating new one breaks because the primary key of the new > table is assigned the same name as the PK of the old, causing CREATE TABLE > to fail. This is really annoying. I think that auto-generated names should > never collide. Can this be accomplished without making auto-generated names ugly? And if not, is it worth the trade-off? > - I suggested that if pg_dump could dump individual schemas, then they could > move their 'don't backup' tables to another schema, and just dump the other > one. FYI, I submitted a patch for this a couple weeks ago (although it hasn't been applied yet...) -- it should be in 7.4 Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Christopher Kings-Lynne wrote: <snip> > We found out all sorts of interesting places that PostgreSQL is being used: > a large Australian Telco, several restaurants in the Perth area, the Debian > inventory system and the Katie revision control system. It is also being > evaluated for process control analysis at a steel plant. Maybe we should > chase some people for case studies? Definitely. Forgot to mention this before, but my gf (Carol Ioanni <cioanni@digitaldistribution.com>) is taking the next couple of weeks to assist us pretty much "full time" as thankfully she has some spare time on her hands for a bit. :) She's been pointed towards our urgent need for Case Studies and has already begun working with a couple of places to assist them in getting them done. We have a "standard waiver" that places need to sign so we're legally in the clear, and a *very* professionally created Case Study Worksheet (donated by Sales.Org for the use of all Free / Open Source Software projects) that places work through and which gives us a very presentable result. Carol should be a real expert at making Case Studies pretty soon now is my guess, as that's all she's going to be doing. ;-) If people could ask the places they have contact with, and whom are using PostgreSQL in significant ways, if they'd be happy to be a reference PostgreSQL Case Study, that would be great. Some places might ask what's in it for them (it's been happening now and again), and pretty much we can tangibly say they'll be included in the PostgreSQL Advocacy and Marketing site's "Case Studies" section, and we'll be making downloadable PDF's of the Case Studies as well so that people can distribute them as needed (i.e. to their CIOs/CEOs/CTOs/etc). For all places that are happy to get involved in this way, please email Carol directly and bring her into the conversation so that we can get them using the same Case Study Worksheet, get the waiver signed, and start grouping and placing the Case Studies appropriately in the Case Studies section. For further background info, the present page views per day of the Advocacy and Marketing site from when the new PostgreSQL portal page went live (broken into week long groupings) are: 5/Jan/03: 2203: +++++++++++++++ 6/Jan/03: 3983: +++++++++++++++++++++++++++ 7/Jan/03: 4493: ++++++++++++++++++++++++++++++ 8/Jan/03: 4889: +++++++++++++++++++++++++++++++++ 9/Jan/03: 4364: ++++++++++++++++++++++++++++++ 10/Jan/03: 3513: ++++++++++++++++++++++++ 11/Jan/03: 2112: +++++++++++++++ 12/Jan/03: 2735: +++++++++++++++++++ 13/Jan/03: 4405: ++++++++++++++++++++++++++++++ 14/Jan/03: 4226: +++++++++++++++++++++++++++++ 15/Jan/03: 3752: ++++++++++++++++++++++++++ 16/Jan/03: 3467: ++++++++++++++++++++++++ 17/Jan/03: 3808: ++++++++++++++++++++++++++ 18/Jan/03: 1932: +++++++++++++ 19/Jan/03: 1777: ++++++++++++ 20/Jan/03: 3641: +++++++++++++++++++++++++ 21/Jan/03: 4025: +++++++++++++++++++++++++++ 22/Jan/03: 3643: +++++++++++++++++++++++++ 23/Jan/03: 3310: +++++++++++++++++++++++ 24/Jan/03: 4242: +++++++++++++++++++++++++++++ 25/Jan/03: 2749: +++++++++++++++++++ 26/Jan/03: 2834: +++++++++++++++++++ 27/Jan/03: 4010: +++++++++++++++++++++++++++ 28/Jan/03: 4081: ++++++++++++++++++++++++++++ Not huge, but not bad for the first version of the site either. Since the Advocacy and Marketing site isn't very large, it means the case studies added there generally do get looked at. Regards and best wishes, Justin Clift > Chris Kings-Lynne -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Linux.conf.au Report
> [ much snipped ]
> * IPV6 data types
> - Apparently there are some ISPs in some countries that have started to bill
> people for IPV6 bandwidth, and the lack of IPV6 address types is hurting
> them.
Yeah. This is a pretty self-contained problem, it just needs someone
who's motivated to work on it. Mostly what we need is to understand how
we want to extend the previously-agreed-to I/O behaviors for IPv4 inet
and cidr types into the v6 domain. (Or should we back up and ask if the
inet/cidr division still makes sense in the v6 world? I hope so, but
if not we should face up to it...)
> ... Maybe we should
> chase some people for case studies?
U betcha ... we were just getting pestered for more of those ...
regards, tom lane
> Yeah. This is a pretty self-contained problem, it just needs someone > who's motivated to work on it. Mostly what we need is to understand how > we want to extend the previously-agreed-to I/O behaviors for IPv4 inet > and cidr types into the v6 domain. (Or should we back up and ask if the > inet/cidr division still makes sense in the v6 world? I hope so, but > if not we should face up to it...) Maybe we should create a new type 'inet6'??? Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Maybe we should create a new type 'inet6'???
I'd lean towards allowing the existing inet and cidr types to store both
v4 and v6 addresses, if at all possible. Is there a good motivation for
doing otherwise?
regards, tom lane
On Thu, 30 Jan 2003, Tom Lane wrote: > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > Maybe we should create a new type 'inet6'??? > > I'd lean towards allowing the existing inet and cidr types to store both > v4 and v6 addresses, if at all possible. Is there a good motivation for > doing otherwise? Different storage for ipv4 vs. ipv6 (why punish ipv4 users with an extra 96 bits of storage?). Use of ipv4 and ipv6 should be mutually exclusive. Extra code in inet type causing bloat. > > regards, tom lane Gavin
On Thursday 30 January 2003 07:42, Gavin Sherry wrote:
> Different storage for ipv4 vs. ipv6 (why punish ipv4 users with an extra
> 96 bits of storage?). Use of ipv4 and ipv6 should be mutually
> exclusive. Extra code in inet type causing bloat.
The inet code has been designed from day one to handle ipv6. It was assumed
that the extra glue would be added when it was needed. I don't see any
reason to change that. I also don't think it adds an extra 12 bytes to ipv4
addresses if you do. The type is variable size if I recall correctly.
Certainly we don't want people to have two different fields for the same piece
of information, an IP address.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
[ pgsql-advocacy trimmed from cc list; seems off-topic for them ]
"D'Arcy J.M. Cain" <darcy@druid.net> writes:
> On Thursday 30 January 2003 07:42, Gavin Sherry wrote:
>> Different storage for ipv4 vs. ipv6 (why punish ipv4 users with an extra
>> 96 bits of storage?). Use of ipv4 and ipv6 should be mutually
>> exclusive. Extra code in inet type causing bloat.
> The inet code has been designed from day one to handle ipv6. It was assumed
> that the extra glue would be added when it was needed. I don't see any
> reason to change that. I also don't think it adds an extra 12 bytes to ipv4
> addresses if you do. The type is variable size if I recall correctly.
Yes, it is; so the "extra storage" argument holds no water. And the
"code bloat" argument doesn't either, that I can see. It's not going to
take more code to incorporate ipv6 functionality as part of an existing
datatype than as part of a new datatype. (If anything, it should take
less code that way; you don't need any extra per-datatype overhead.)
> Certainly we don't want people to have two different fields for the
> same piece of information, an IP address.
That's the main argument in my mind. If a user *wants* to segregate
ipv4 and v6 addresses, he can do so in any case --- but if he'd rather
have a column that could be either kind, only the unified-datatype
approach will be convenient for him.
Why exactly should "use of ipv4 and ipv6 be mutually exclusive"?
I don't see the argument for that. (It'd have to be an argument that
doesn't just establish a scenario where you'd want that, but proves
that we should force that point of view upon every application using
IP addresses.)
regards, tom lane
What about cases where I only want one or the other? Would a simple method exist to limit input to v4 or v6 only? Also, what are the implications to functions such as network_sub, network_cmp, etc. when given mixed v4/v6 inputs as could easily happen if the two are freely mixed in the same data type? Cheers, Steve On Wednesday 29 January 2003 10:04 pm, Tom Lane wrote: > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > Maybe we should create a new type 'inet6'??? > > I'd lean towards allowing the existing inet and cidr types to store both > v4 and v6 addresses, if at all possible. Is there a good motivation for > doing otherwise? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org
Steve Crawford <scrawford@pinpointresearch.com> writes:
> What about cases where I only want one or the other? Would a simple method
> exist to limit input to v4 or v6 only?
I would assume we'd add a test function like is_v6(inet). Given that,
you could add a check constraint "is_v6(col)" or "NOT is_v6(col)" to
any column that you want to restrict.
> Also, what are the implications to functions such as network_sub,
> network_cmp, etc. when given mixed v4/v6 inputs as could easily happen if the
> two are freely mixed in the same data type?
We have to work out what the semantics should be. I don't know anything
about v6, but I'd imagine v4 addresses form a defined subset of the v6
address space ... if so the semantics seem pretty straightforward.
regards, tom lane
On Thu, Jan 30, 2003 at 09:48:37AM -0500, Tom Lane wrote: > I don't see the argument for that. (It'd have to be an argument that > doesn't just establish a scenario where you'd want that, but proves > that we should force that point of view upon every application using > IP addresses.) Given that IPv6 is supposed to allow co-operation with IPv4, it seems it'd be pretty hard to force such a view on every application using IP addresses. DNS, for instance. A -- ---- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M2P 2A8 +1 416 646 3304 x110
On Thu, Jan 30, 2003 at 11:28:41AM -0500, Tom Lane wrote: > > > Also, what are the implications to functions such as network_sub, > > network_cmp, etc. when given mixed v4/v6 inputs as could easily happen if the > > two are freely mixed in the same data type? > > We have to work out what the semantics should be. I don't know anything > about v6, but I'd imagine v4 addresses form a defined subset of the v6 > address space ... if so the semantics seem pretty straightforward. You have a "ipv4 mapped ipv6 address". The ipv4 address 1.2.3.4 becomes ::ffff:1.2.3.4. But I'm not really in favour of automatically changing an ipv4 address to an ipv6 address. And you really shouldn't return an ipv4 address as an ipv6 address. Some thing you also shouldn't forget for ipv6 addresses is the scope. An address with a scope of the link can be assigned to several interfaces. If they want to differentiate between them, should they be able to store it the same field, or use a different one? My question really is how you're going to store it. Are you going to store is as a character string, or as binary? If you store is as binary, how will you know if it's an ipv4 or ipv6 address? Based on the size? From an application point of view it's more handy if you have a combination of the address family and the data, so they don't have to guess all the time. P.S.: I don't really like the ipv6 patch. It's more complicated than it should be. I really don't have the time to fix it/do it better though. Kurt
Kurt Roeckx <Q@ping.be> writes:
> On Thu, Jan 30, 2003 at 11:28:41AM -0500, Tom Lane wrote:
>> We have to work out what the semantics should be. I don't know anything
>> about v6, but I'd imagine v4 addresses form a defined subset of the v6
>> address space ... if so the semantics seem pretty straightforward.
> You have a "ipv4 mapped ipv6 address". The ipv4 address 1.2.3.4 becomes
> ::ffff:1.2.3.4. But I'm not really in favour of automatically
> changing an ipv4 address to an ipv6 address. And you really
> shouldn't return an ipv4 address as an ipv6 address.
No, we should keep the distinction for purposes of storage and display.
The question was about what the semantics should be when comparing v4
and v6 addresses in operations like network_sub. It seems perfectly
reasonable to convert the v4 address to the mapped v6 equivalent and then
do a v6 comparison in that situation. Do we have any operators where
this would not be a sensible definition?
> My question really is how you're going to store it. Are you
> going to store is as a character string, or as binary?
Binary, same as we do now for v4.
> If you store is as binary, how will you know if it's an ipv4 or
> ipv6 address? Based on the size?
Why not?
regards, tom lane
On Thu, 30 Jan 2003, Andrew Sullivan wrote:
> Given that IPv6 is supposed to allow co-operation with IPv4, it seems
> it'd be pretty hard to force such a view on every application using
> IP addresses. DNS, for instance.
Hm? DNS completely separates IPv4 and IPv6 addresses; they're different
record types ("A" versus "AAAA") in the DNS "database".
And the "interoperation" if IPv4 and IPv6 is pretty much not happening,
if you're talking about the compatability addresses. I won't get into
all the reasons why.
All that said, I'm not advocating separating (or not separating)
IPv4 and IPv6 addresses. I'm still undecided on the issue. I can see
situations where I might want to store both together, but then again, I
can see situations where I certainly wouldn't.
Perhaps we should think about another example to try to illuminate this:
what about storing ISO/OSI addresses in the same type as well? Isn't
that just the same thing as storing IPv4 and IPv6 addresses together?
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC
On Thu, 2003-01-30 at 19:57, Curt Sampson wrote:
> On Thu, 30 Jan 2003, Andrew Sullivan wrote:
>
> > Given that IPv6 is supposed to allow co-operation with IPv4, it seems
> > it'd be pretty hard to force such a view on every application using
> > IP addresses. DNS, for instance.
>
> Hm? DNS completely separates IPv4 and IPv6 addresses; they're different
> record types ("A" versus "AAAA") in the DNS "database".
>
> And the "interoperation" if IPv4 and IPv6 is pretty much not happening,
> if you're talking about the compatability addresses. I won't get into
> all the reasons why.
>
> All that said, I'm not advocating separating (or not separating)
> IPv4 and IPv6 addresses. I'm still undecided on the issue. I can see
> situations where I might want to store both together, but then again, I
> can see situations where I certainly wouldn't.
>
> Perhaps we should think about another example to try to illuminate this:
> what about storing ISO/OSI addresses in the same type as well? Isn't
> that just the same thing as storing IPv4 and IPv6 addresses together?
>
> cjs
That's because IPv6 is a completely new and different protocol from
IPv4. It has new address requirements and is completely distinct from
IPv4. For some reason, people can't wait to lump the two together.
Make no mistake about it, IPv4 and IPv6 share pretty much a name and
that's about it.
IPv6 has some provisions to help people migrate toward it (from IPv4),
however, IPv6 is a distinctly different protocol. It doesn't help the
confusion that many OS's try to confuse programmers by exposing a single
socket interface, etc. Simple fact remains, IPv6 is not IPv4.
Wish more people would remember this.
...sorry...that's my rant for today... ;)
Regards,
Greg
--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting
On Thu, 30 Jan 2003, Tom Lane wrote: > I don't know anything > about v6, but I'd imagine v4 addresses form a defined subset of the v6 > address space ... No, they do not. The address spaces are completely independent. (There is a "compatability space" for IPv4 addresses, but it turned out to be impractical, and thus is generally not used. Certainly you cannot route to arbitrary v4 hosts using a v6 address.) cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC
On Fri, Jan 31, 2003 at 10:57:17AM +0900, Curt Sampson wrote:
> Hm? DNS completely separates IPv4 and IPv6 addresses; they're different
> record types ("A" versus "AAAA") in the DNS "database".
>
> And the "interoperation" if IPv4 and IPv6 is pretty much not happening,
> if you're talking about the compatability addresses. I won't get into
> all the reasons why.
I know it's not happening. On the other hand, IPv6 isn't happening
terribly much, either.
Soon, the NAT + CIDR bag-on-the-side will run out of room, and people
will have no choice but to use IPv6. But the pain of making them
interoperate is part of the cause of resistance. The compatibility
addresses are going to _have_ to work if people are really going to
move, unless someone is contemplating another great TCP/IP cutover
day. (And that didn't even work last time, when several networks
just dropped right off the proto-Net for a while.) So it seems to me
that the compatibility addresses are going to need to be supported by
any IPv6-aware system.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8 +1 416 646 3304
x110
On Thu, Jan 30, 2003 at 08:21:09PM -0600, Greg Copeland wrote: > > IPv6 has some provisions to help people migrate toward it (from IPv4), > however, IPv6 is a distinctly different protocol. The ipv4 mapped ipv6 addresses are to help migrate, but it actually makes things worse. If this wouldn't be the case, some software wouldn't look as ugly as it does now. Then there is the "problem" that BSD no longer really supports the ipv4 mapped ipv6 addresses. It will refuse to use such an address on an AF_INET6 socket, while that (still) works on other OSs. The badly ported software will not work on them. > It doesn't help the > confusion that many OS's try to confuse programmers by exposing a single > socket interface, etc. Simple fact remains, IPv6 is not IPv4. It's a good things that the socket interface can actually work with all protocol! It doesn't only work with AF_INET, but also AF_UNIX, and probably others. It's a good things that things like socket(), bind(), connect() don't need to be replaced by other things. The new protocol independed API for translation between host name and address, in both text and binary representation is also a good thing. The struct addrinfo is really useful, since you can store all info you need in it for all calls to the socket API. The ipv6 patch really should make better use of it, both if you have and don't have ipv6 support, and get rid of most of those #ifdefs. Kurt
On Fri, Jan 31, 2003 at 09:13:18AM -0500, Andrew Sullivan wrote: > > Soon, the NAT + CIDR bag-on-the-side will run out of room, and people > will have no choice but to use IPv6. But the pain of making them > interoperate is part of the cause of resistance. The compatibility > addresses are going to _have_ to work if people are really going to > move, unless someone is contemplating another great TCP/IP cutover > day. What do you mean with "compatibility addresses"? I don't know of any such thing. The ipv4 mapped ipv6 address is just a "hack" on the local system. You never see those "on the wire". Anyway, what is the problem? ipv4 and ipv6 can happely live on the same network, it does so far a long time now. Host just support both ipv4 and ipv6 now. If an application is written properly, you shouldn't even notice the connection is over ipv4 or ipv6. Kurt
On Thu, Jan 30, 2003 at 08:13:30PM -0500, Tom Lane wrote: > Kurt Roeckx <Q@ping.be> writes: > > On Thu, Jan 30, 2003 at 11:28:41AM -0500, Tom Lane wrote: > >> We have to work out what the semantics should be. I don't know anything > >> about v6, but I'd imagine v4 addresses form a defined subset of the v6 > >> address space ... if so the semantics seem pretty straightforward. > > > You have a "ipv4 mapped ipv6 address". The ipv4 address 1.2.3.4 becomes > > ::ffff:1.2.3.4. But I'm not really in favour of automatically > > changing an ipv4 address to an ipv6 address. And you really > > shouldn't return an ipv4 address as an ipv6 address. > > No, we should keep the distinction for purposes of storage and display. > The question was about what the semantics should be when comparing v4 > and v6 addresses in operations like network_sub. It seems perfectly > reasonable to convert the v4 address to the mapped v6 equivalent and then > do a v6 comparison in that situation. Do we have any operators where > this would not be a sensible definition? broadcast() doesn't make sense for ipv6. There is no such thing. network() might be useful, but mean something a little bit different. Ipv6 calls the mask length the prefix length ... abbrev() might also need some tweaking, specially in combination with the compressed format. Not sure if abbrev() is really useful. There seems to be no documentation on network_sub, but I assume it's the same as "<<". It shouldn't be a problem converting it to the ipv6 address, and adding 96 to the mask. Kurt
On Fri, 2003-01-31 at 13:04, Kurt Roeckx wrote: > On Thu, Jan 30, 2003 at 08:21:09PM -0600, Greg Copeland wrote: > > It doesn't help the > > confusion that many OS's try to confuse programmers by exposing a single > > socket interface, etc. Simple fact remains, IPv6 is not IPv4. > > It's a good things that the socket interface can actually work > with all protocol! It doesn't only work with AF_INET, but also > AF_UNIX, and probably others. It's a good things that things > like socket(), bind(), connect() don't need to be replaced by > other things. That's actually not what I was talking about. Please see the recent IPv6 support thread as an example. The fact that an OS allows IPv4 connections to be completed even though you explicitly requested IPv6 protocol, only adds to much confusion (one of many such oddities which some OS's allow). Heck, along those lines, they should allow NCP connections to come through too. Or, how about UDP traffic on TCP sockets. If I wanted IPv4 traffic, I'll ask for it. Likewise of IPv6. My point being, too many people are in a hurry to confuse/combine the two when they are very clearly two distinct protocols, each having distinct needs. The faster people treat them as such, the quicker things will become better for everyone. The fact that some OS's attempt to blur the API lines and underlying semantics between the two protocols only further confuses things as it falsely leads people to believe that they are more or less the same protocol. Regards, -- Greg Copeland <greg@copelandconsulting.net> Copeland Computer Consulting
On Fri, Jan 31, 2003 at 08:21:21PM +0100, Kurt Roeckx wrote:
> What do you mean with "compatibility addresses"? I don't know of
> any such thing.
I'm thinking of these sorts of things (my faviourite description,
from RFC 2893):
IPv6/IPv4 nodes that perform automatic tunneling are assigned
IPv4-compatible address. An IPv4-compatible address is identified by
an all-zeros 96-bit prefix, and holds an IPv4 address in the
low-order 32-bits. IPv4-compatible addresses are structured as
follows:
| 96-bits | 32-bits |
+--------------------------------------+--------------+ | 0:0:0:0:0:0 | IPv4 Address |
+--------------------------------------+--------------+ IPv4-Compatible IPv6 Address Format
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8 +1 416 646 3304
x110
On Fri, 31 Jan 2003, Andrew Sullivan wrote: > But the pain of making them > interoperate is part of the cause of resistance. The compatibility > addresses are going to _have_ to work if people are really going to > move... There is no pain in this respect; you get your compatability by simply running both IPv4 and IPv6 on the hosts that interoperate. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
On Fri, Jan 31, 2003 at 06:51:49PM -0500, Andrew Sullivan wrote: > On Fri, Jan 31, 2003 at 08:21:21PM +0100, Kurt Roeckx wrote: > > What do you mean with "compatibility addresses"? I don't know of > > any such thing. > > | 96-bits | 32-bits | > +--------------------------------------+--------------+ > | 0:0:0:0:0:0 | IPv4 Address | > +--------------------------------------+--------------+ > IPv4-Compatible IPv6 Address Format Oh, those. I forgot about them. I've never seen anybody using them, and I can't think of a good reason to use them either. They're not even routable now. Kurt
On Fri, 31 Jan 2003, Kurt Roeckx wrote: > It's a good things that the socket interface can actually work > with all protocol! It doesn't only work with AF_INET, but also > AF_UNIX, and probably others. It's a good things that things > like socket(), bind(), connect() don't need to be replaced by > other things. Sure. But you still want to be able to say (and can say, in some [many?] socket API implementations) that you want to accept only IPv4 or only IPv6 connections. I also want to be able to say the same thing in my database. So probably, this means setting up separate types for IPv4 and IPv6 addresses, and a third type to hold both IPv4 and IPv6 addresses. That third type could also be extended to hold OSI, NS, and whatever other type of addresses people feel would be useful. I suppose another way of implementing this would be to set up some easy way to put a constraint on a column such that you could constrain it to hold only IPv4 or IPv6 addresses. And I would be interested to hear the opinions of those who want to put IPv4 and IPv6 addresses in the same type as to whether you do or do not support also putting ISO/OSI and Novell addresses into that type as well, and why or why not. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote: > > Sure. But you still want to be able to say (and can say, in some [many?] > socket API implementations) that you want to accept only IPv4 or only IPv6 > connections. I also want to be able to say the same thing in my database. You just create either an ipv4 or ipv6 socket. And then you can bind to an address of that type if you want. Either all addresses or a specific one. Depending on the OS, binding to all addresses on IPv6 will also bind to all the ipv4 addresses, which can be both handy an annoying. On others you need 2 sockets if you want to listen on both ipv4 and ipv6, which makes more sense. Kurt
Kurt Roeckx wrote:
> On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote:
> >
> > Sure. But you still want to be able to say (and can say, in some [many?]
> > socket API implementations) that you want to accept only IPv4 or only IPv6
> > connections. I also want to be able to say the same thing in my database.
>
> You just create either an ipv4 or ipv6 socket. And then you can
> bind to an address of that type if you want. Either all
> addresses or a specific one.
>
> Depending on the OS, binding to all addresses on IPv6 will also
> bind to all the ipv4 addresses, which can be both handy an
> annoying. On others you need 2 sockets if you want to listen on
> both ipv4 and ipv6, which makes more sense.
Well, that's interesting. Current CVS only binds to IPv6, and assumes
IPv4 will work too. If some OS's require a separate Ipv4 binding, we
are going to hear about it before 7.4:
---------------------------------------------------------------------------
#ifdef HAVE_IPV6 /* Try INET6 first. May fail if kernel doesn't support IP6 */ status =
StreamServerPort(AF_INET6,VirtualHost, (unsigned short) PostPortNumber,
UnixSocketDir, &ServerSock_INET); if (status != STATUS_OK) {
elog(LOG, "IPv6 support disabled --- perhaps the kernel does not support IPv6");
#endif status = StreamServerPort(AF_INET, VirtualHost, (unsigned short)
PostPortNumber, UnixSocketDir,
&ServerSock_INET); if (status != STATUS_OK) { postmaster_error("cannot create INET
streamport"); ExitPostmaster(1); }
#ifdef HAVE_IPV6 else elog(LOG, "IPv4 socket created"); }
#endif }
-- 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,
Pennsylvania19073
On Sun, Feb 02, 2003 at 08:19:23AM -0500, Bruce Momjian wrote: > Kurt Roeckx wrote: > > Depending on the OS, binding to all addresses on IPv6 will also > > bind to all the ipv4 addresses, which can be both handy an > > annoying. On others you need 2 sockets if you want to listen on > > both ipv4 and ipv6, which makes more sense. > > Well, that's interesting. Current CVS only binds to IPv6, and assumes > IPv4 will work too. If some OS's require a separate Ipv4 binding, we > are going to hear about it before 7.4: It will not work on atleast OpenBSD. I believe it won't work on the other BSDs in the future either. Kurt
On Sun, 2 Feb 2003, Bruce Momjian wrote: > Kurt Roeckx wrote: > > On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote: > > > > > > Sure. But you still want to be able to say (and can say, in some [many?] > > > socket API implementations) that you want to accept only IPv4 or only IPv6 > > > connections. I also want to be able to say the same thing in my database. > > > > You just create either an ipv4 or ipv6 socket. And then you can > > bind to an address of that type if you want. Either all > > addresses or a specific one. > > > > Depending on the OS, binding to all addresses on IPv6 will also > > bind to all the ipv4 addresses, which can be both handy an > > annoying. On others you need 2 sockets if you want to listen on > > both ipv4 and ipv6, which makes more sense. > > Well, that's interesting. Current CVS only binds to IPv6, and assumes > IPv4 will work too. If some OS's require a separate Ipv4 binding, we > are going to hear about it before 7.4: I don't think we should listen on IPv6 just because it is supported. It should be a configuration variable: tcpip_socket = true ipv6 = true Gavin
Gavin Sherry wrote: > On Sun, 2 Feb 2003, Bruce Momjian wrote: > > > Kurt Roeckx wrote: > > > On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote: > > > > > > > > Sure. But you still want to be able to say (and can say, in some [many?] > > > > socket API implementations) that you want to accept only IPv4 or only IPv6 > > > > connections. I also want to be able to say the same thing in my database. > > > > > > You just create either an ipv4 or ipv6 socket. And then you can > > > bind to an address of that type if you want. Either all > > > addresses or a specific one. > > > > > > Depending on the OS, binding to all addresses on IPv6 will also > > > bind to all the ipv4 addresses, which can be both handy an > > > annoying. On others you need 2 sockets if you want to listen on > > > both ipv4 and ipv6, which makes more sense. > > > > Well, that's interesting. Current CVS only binds to IPv6, and assumes > > IPv4 will work too. If some OS's require a separate Ipv4 binding, we > > are going to hear about it before 7.4: > > I don't think we should listen on IPv6 just because it is supported. It > should be a configuration variable: > > tcpip_socket = true > ipv6 = true We had a huge discussion on this. I think you were away for it. You can control what you listen on by modifying pg_hba.conf. -- 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, Pennsylvania19073
On Sun, 2 Feb 2003, Kurt Roeckx wrote: > On Sat, Feb 01, 2003 at 02:35:15PM +0900, Curt Sampson wrote: > > > > Sure. But you still want to be able to say (and can say, in some [many?] > > socket API implementations) that you want to accept only IPv4 or only IPv6 > > connections. I also want to be able to say the same thing in my database. > > You just create either an ipv4 or ipv6 socket. Um...I'm talking about inserting data into a column in postgres. How do I declare that a column can accept IPv4 addresses only? And why will *nobody* address the question of whether this type should include ISO/OSI addresses or not, and why? cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Gavin Sherry wrote:
>> I don't think we should listen on IPv6 just because it is supported. It
>> should be a configuration variable:
>>
>> tcpip_socket = true
>> ipv6 = true
> We had a huge discussion on this. I think you were away for it. You
> can control what you listen on by modifying pg_hba.conf.
Can you actually control whether the postmaster is listening by
modifying pg_hba.conf? I don't think so.
I think I was the one who talked us into assuming that ipv4 and ipv6
should be treated as a single protocol. But some people have since made
pretty good cases that it's better to regard them as separate protocols.
Perhaps we should rethink that decision.
regards, tom lane
On Sun, 2 Feb 2003, Tom Lane wrote: > I think I was the one who talked us into assuming that ipv4 and ipv6 > should be treated as a single protocol. But some people have since made > pretty good cases that it's better to regard them as separate protocols. From a security standpoint, I think it's definitely better to regard them as separate protocols. They are certainly separately filtered on firewalls, and they are often routed differently, too. That said, I see no reason not to have some sort of easy way of saying, "listen on all the interfaces you can find using all the protocols you know." So long as you have the ability to distinguish where you listen by both protocol and address, it's easy to be as secure as you need to be. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
On Sun, Feb 02, 2003 at 12:49:34PM -0500, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Gavin Sherry wrote: > >> I don't think we should listen on IPv6 just because it is supported. It > >> should be a configuration variable: > >> > >> tcpip_socket = true > >> ipv6 = true > > > We had a huge discussion on this. I think you were away for it. You > > can control what you listen on by modifying pg_hba.conf. > > Can you actually control whether the postmaster is listening by > modifying pg_hba.conf? I don't think so. Why isn't virtual_host used for deciding to what addresses it should listen? It currently only seems to support 1 address, and I don't really know why. Is there a reason you can't make this a list of hostnames/ip addresses? It really is where it belongs. Kurt
Kurt Roeckx <Q@ping.be> writes:
> [virtual_host] currently only seems to support 1 address, and I don't really
> know why. Is there a reason you can't make this a list of
> hostnames/ip addresses?
That was what the boys at uu.net needed, so that's what they
implemented. If you need more, I think a patch would be accepted ...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Gavin Sherry wrote: > >> I don't think we should listen on IPv6 just because it is supported. It > >> should be a configuration variable: > >> > >> tcpip_socket = true > >> ipv6 = true > > > We had a huge discussion on this. I think you were away for it. You > > can control what you listen on by modifying pg_hba.conf. > > Can you actually control whether the postmaster is listening by > modifying pg_hba.conf? I don't think so. Good question. I assumed if you removed the IPv6 local address that a local IPv6 wouldn't work, and that you need to specify an IPv6 remote host to have it be accepted. Yes, it is still listening on Ipv6, but no one can get in except localhost by default, so I don't see the issue. > I think I was the one who talked us into assuming that ipv4 and ipv6 > should be treated as a single protocol. But some people have since made > pretty good cases that it's better to regard them as separate protocols. > Perhaps we should rethink that decision. Sure. -- 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, Pennsylvania19073
Is Linux.conf.au the event PostgreSQL should use for coverage in Australia next year? --------------------------------------------------------------------------- Christopher Kings-Lynne wrote: > Linux.conf.au Report > -------------------- > > The Linux.conf.au is an international Linux/Open Source event that attracts > lots of international speakers. Total conf attendance was around 360, maybe > even 400 I think. > > Gavin Sherry was speaking at this particular conf, and I attended as a > hobbyist. > > PostgreSQL got a reasonable amount of attention, particularly since there > were no representatives from other database products there. > > Some pics of our PostgreSQL BOF and the Perth Bell Tower: > http://www.zip.com.au/~swm/lca2003 > (Gavin is the beardy looking dude 3rd from the left :) I'm taking the > photo.) > > These are the main questions we where asked, or features that were > requested: > > * Replication, replication, replication! > > - We told them that there are a few solutions, none of them are particularly > great. Gavin got all sorts of ideas about log shipping. > > * IPV6 data types > > - Apparently there are some ISPs in some countries that have started to bill > people for IPV6 bandwidth, and the lack of IPV6 address types is hurting > them. > > * Collisions in auto-generated names. > > - The standard table modification tactic (that I also use) or renaming table > to *_old and creating new one breaks because the primary key of the new > table is assigned the same name as the PK of the old, causing CREATE TABLE > to fail. This is really annoying. I think that auto-generated names should > never collide. > > * Problem: person has large database with 4 or 5 humungous tables that they > aren't interested in backing up. However, they want to back up the rest. > > - I suggested that if pg_dump could dump individual schemas, then they could > move their 'don't backup' tables to another schema, and just dump the other > one. > > We found out all sorts of interesting places that PostgreSQL is being used: > a large Australian Telco, several restaurants in the Perth area, the Debian > inventory system and the Katie revision control system. It is also being > evaluated for process control analysis at a steel plant. Maybe we should > chase some people for case studies? > > Chris Kings-Lynne > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- 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
I think so - Gavin? As far as I'm aware there's not really anything else on the open source circuit. There is often a MySQL rep there as well apparently. Chris On Fri, 14 Feb 2003, Bruce Momjian wrote: > > Is Linux.conf.au the event PostgreSQL should use for coverage in > Australia next year? > > --------------------------------------------------------------------------- > > Christopher Kings-Lynne wrote: > > Linux.conf.au Report > > -------------------- > > > > The Linux.conf.au is an international Linux/Open Source event that attracts > > lots of international speakers. Total conf attendance was around 360, maybe > > even 400 I think. > > > > Gavin Sherry was speaking at this particular conf, and I attended as a > > hobbyist. > > > > PostgreSQL got a reasonable amount of attention, particularly since there > > were no representatives from other database products there. > > > > Some pics of our PostgreSQL BOF and the Perth Bell Tower: > > http://www.zip.com.au/~swm/lca2003 > > (Gavin is the beardy looking dude 3rd from the left :) I'm taking the > > photo.) > > > > These are the main questions we where asked, or features that were > > requested: > > > > * Replication, replication, replication! > > > > - We told them that there are a few solutions, none of them are particularly > > great. Gavin got all sorts of ideas about log shipping. > > > > * IPV6 data types > > > > - Apparently there are some ISPs in some countries that have started to bill > > people for IPV6 bandwidth, and the lack of IPV6 address types is hurting > > them. > > > > * Collisions in auto-generated names. > > > > - The standard table modification tactic (that I also use) or renaming table > > to *_old and creating new one breaks because the primary key of the new > > table is assigned the same name as the PK of the old, causing CREATE TABLE > > to fail. This is really annoying. I think that auto-generated names should > > never collide. > > > > * Problem: person has large database with 4 or 5 humungous tables that they > > aren't interested in backing up. However, they want to back up the rest. > > > > - I suggested that if pg_dump could dump individual schemas, then they could > > move their 'don't backup' tables to another schema, and just dump the other > > one. > > > > We found out all sorts of interesting places that PostgreSQL is being used: > > a large Australian Telco, several restaurants in the Perth area, the Debian > > inventory system and the Katie revision control system. It is also being > > evaluated for process control analysis at a steel plant. Maybe we should > > chase some people for case studies? > > > > Chris Kings-Lynne > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to majordomo@postgresql.org so that your > > message can get through to the mailing list cleanly > > > > -- > 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 >
On Sat, 15 Feb 2003, Christopher Kings-Lynne wrote: > I think so - Gavin? As far as I'm aware there's not really anything else > on the open source circuit. There is often a MySQL rep there as well > apparently. Chris is right. David Axmark (MySQL AB) usually turns up, but he didn't this year. The conference has an attendence of 400 people. The audience is fairly technical -- getting less so each year though :-(. If I go next year, I think I will give a tutorial focusing on migrating MySQL applications to PostgreSQL. Many attendees of my talk this year were looking for information like that -- something I didn't cover :-\. Gavin