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.
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 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, 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 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
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