Thread: Seems we need a post-beta1 initdb already

Seems we need a post-beta1 initdb already

From
Tom Lane
Date:
As Martin Pitt pointed out in this pgsql-bugs thread
http://archives.postgresql.org/pgsql-bugs/2007-10/msg00089.php
we have managed to create an ABI break between 8.2 and 8.3 libpq
by renumbering encoding IDs in pg_wchar.h.  Although perhaps this
does not hurt any third-party clients, it does break our own initdb
and psql programs, which turn out to be dependent on libpq and the
backend having the same numbering.  Going forward we should try to
fix things so that the exact values of those IDs need not be considered
part of libpq's ABI, but that doesn't get us out of the fact that 8.2
psql will fail if you try to use it with CVS HEAD libpq.so.

It seems that we are faced with a choice of two evils:

1.  Accept that there's an ABI break and increment libpq.so's major
version number for 8.3.  This will be a PITA for packagers, who will
have to carry a compatibility package to provide 8.2 libpq.so.

2.  Renumber 8.3's encoding IDs to preserve compatibility with the
8.2 values.  It turns out that we can do that, but we will have to
force initdb because the contents of pg_database.encoding will change.

I'm of the opinion that #2 is the lesser evil, but maybe I'm overly
influenced by my Red Hat packaging responsibilities --- I'll personally
have to spend time on a compatibility package if we go with #1.
Other opinions out there?

Also, if we do #2 it means that we have the option to resolve the
contrib/txid mess by pushing txid into the core backend before beta2.
Any votes pro or con on that?
        regards, tom lane


Re: Seems we need a post-beta1 initdb already

From
Andrew Dunstan
Date:

Tom Lane wrote:
> I'm of the opinion that #2 is the lesser evil, but maybe I'm overly
> influenced by my Red Hat packaging responsibilities --- I'll personally
> have to spend time on a compatibility package if we go with #1.
> Other opinions out there?
>
> Also, if we do #2 it means that we have the option to resolve the
> contrib/txid mess by pushing txid into the core backend before beta2.
> Any votes pro or con on that?
>
>             
>   

#2 by all means. Post-beta initdb is mildly unfortunate; compatibility 
packages are to be avoided far more.

+1 to put txid in core, where it belongs.

cheers

andrew


Re: Seems we need a post-beta1 initdb already

From
Darcy Buskermolen
Date:
On Friday 12 October 2007 15:41:58 Tom Lane wrote:
> As Martin Pitt pointed out in this pgsql-bugs thread
> http://archives.postgresql.org/pgsql-bugs/2007-10/msg00089.php
> we have managed to create an ABI break between 8.2 and 8.3 libpq
> by renumbering encoding IDs in pg_wchar.h.  Although perhaps this
> does not hurt any third-party clients, it does break our own initdb
> and psql programs, which turn out to be dependent on libpq and the
> backend having the same numbering.  Going forward we should try to
> fix things so that the exact values of those IDs need not be considered
> part of libpq's ABI, but that doesn't get us out of the fact that 8.2
> psql will fail if you try to use it with CVS HEAD libpq.so.
>
> It seems that we are faced with a choice of two evils:
>
> 1.  Accept that there's an ABI break and increment libpq.so's major
> version number for 8.3.  This will be a PITA for packagers, who will
> have to carry a compatibility package to provide 8.2 libpq.so.
>
> 2.  Renumber 8.3's encoding IDs to preserve compatibility with the
> 8.2 values.  It turns out that we can do that, but we will have to
> force initdb because the contents of pg_database.encoding will change.
>
> I'm of the opinion that #2 is the lesser evil, but maybe I'm overly
> influenced by my Red Hat packaging responsibilities --- I'll personally
> have to spend time on a compatibility package if we go with #1.
> Other opinions out there?
>
> Also, if we do #2 it means that we have the option to resolve the
> contrib/txid mess by pushing txid into the core backend before beta2.
> Any votes pro or con on that?

I vote that adding txid to the backend now will be of better value for all 
parties involved than not, given it's coming without any particular pain. 
(though I may be a bit biased on this).  By having it in core it's one less 
thing that skytools/slony needs to detect and error out on with an message 
saying install contrib/txid during their install phases.  Not to mention this 
puts having replication that much more likely to be available in shared 
hosting environments who by all reports loth installing contrib for their 
customers.



>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: 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




Re: Seems we need a post-beta1 initdb already

From
Michael Glaesemann
Date:
On Oct 12, 2007, at 17:41 , Tom Lane wrote:

> Also, if we do #2 it means that we have the option to resolve the
> contrib/txid mess by pushing txid into the core backend before beta2.
> Any votes pro or con on that?

+1

Michael Glaesemann
grzm seespotcode net




Re: Seems we need a post-beta1 initdb already

From
Devrim GÜNDÜZ
Date:
Hi,

On Fri, 2007-10-12 at 18:41 -0400, Tom Lane wrote:
>
> I'm of the opinion that #2 is the lesser evil, but maybe I'm overly
> influenced by my Red Hat packaging responsibilities --- I'll
> personally
> have to spend time on a compatibility package if we go with #1.
> Other opinions out there?
>
> Also, if we do #2 it means that we have the option to resolve the
> contrib/txid mess by pushing txid into the core backend before beta2.
> Any votes pro or con on that?

I am also for #2 (and yes, I want to avoid yet another compat rpm
problem...)

Regards,
--
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/



Re: Seems we need a post-beta1 initdb already

From
"Magnus Hagander"
Date:
> It seems that we are faced with a choice of two evils:
> 
> 1.  Accept that there's an ABI break and increment libpq.so's major
> version number for 8.3.  This will be a PITA for packagers, who will
> have to carry a compatibility package to provide 8.2 libpq.so.
> 
> 2.  Renumber 8.3's encoding IDs to preserve compatibility with the
> 8.2 values.  It turns out that we can do that, but we will have to
> force initdb because the contents of pg_database.encoding will change.
> 
> I'm of the opinion that #2 is the lesser evil, but maybe I'm overly
> influenced by my Red Hat packaging responsibilities --- I'll personally
> have to spend time on a compatibility package if we go with #1.
> Other opinions out there?

#2 seems like a much better choice. A small inconvenience during beta is much better than one in the actual release.

People running the beta expects us to try not to force initdb, but also that we'll do it if we have to.

Might be worthwhile to try to get beta2 out as quickly as we can after the changes are in, to minimize the number of
peoplewho will need it?
 
> Also, if we do #2 it means that we have the option to resolve the
> contrib/txid mess by pushing txid into the core backend before beta2.
> Any votes pro or con on that?

Absolutely pro.

/Magnus 


Re: Seems we need a post-beta1 initdb already

From
Tom Lane
Date:
"Magnus Hagander" <magnus@hagander.net> writes:
> Might be worthwhile to try to get beta2 out as quickly as we can after the changes are in, to minimize the number of
peoplewho will need it?
 

I'd like to get the locale/encoding issues straightened out, and also
get the contrib-tsearch-examples stuff in, before we think about beta2.
But hopefully that won't take very long.
        regards, tom lane