Обсуждение: Linux.conf.au 2003 Report

Поиск
Список
Период
Сортировка

Linux.conf.au 2003 Report

От
"Christopher Kings-Lynne"
Дата:
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


Re: Linux.conf.au 2003 Report

От
Neil Conway
Дата:
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




Re: Linux.conf.au 2003 Report

От
Justin Clift
Дата:
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


Re: [HACKERS] Linux.conf.au 2003 Report

От
Tom Lane
Дата:
"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

Re: [HACKERS] Linux.conf.au 2003 Report

От
"Christopher Kings-Lynne"
Дата:
> 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


Re: [HACKERS] Linux.conf.au 2003 Report

От
Tom Lane
Дата:
"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

Re: [HACKERS] Linux.conf.au 2003 Report

От
Gavin Sherry
Дата:
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



Re: [HACKERS] Linux.conf.au 2003 Report

От
"D'Arcy J.M. Cain"
Дата:
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.

Re: [HACKERS] Linux.conf.au 2003 Report

От
Steve Crawford
Дата:
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

Re: [HACKERS] Linux.conf.au 2003 Report

От
Tom Lane
Дата:
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

Re: [HACKERS] Linux.conf.au 2003 Report

От
Kurt Roeckx
Дата:
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


Re: [HACKERS] Linux.conf.au 2003 Report

От
Tom Lane
Дата:
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

Re: [HACKERS] Linux.conf.au 2003 Report

От
Curt Sampson
Дата:
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

Re: [HACKERS] Linux.conf.au 2003 Report

От
Kurt Roeckx
Дата:
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


Re: [HACKERS] Linux.conf.au 2003 Report

От
Bruce Momjian
Дата:
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

Re: [HACKERS] Linux.conf.au 2003 Report

От
Christopher Kings-Lynne
Дата:
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
>


Re: [HACKERS] Linux.conf.au 2003 Report

От
Gavin Sherry
Дата:
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