Обсуждение: Seems we need a post-beta1 initdb already
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
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
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
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
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/
> 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
"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