Обсуждение: Which installation parts are backward compatible?
I've been examining multi-major-version binary packaging again, and I was wondering whether we have a good overview over which pieces of the installation are backward compatible (that is, they can be shared between all major versions) and which are not. For example, psql 8.4 can now presumably be shared between all major versions, so previous schemes to have several psqls installed can be simpified. Here is a start: Item Compatible across major versions? (i.e. the 8.4 version works with 7.4+ server) clusterdb yes? createdb yes? createlang yes? createuser yes? dropdb yes? droplang yes? dropuser yes? ecpg no? initdb NO pg_config (should be kept around for each major version) pg_controldata NO pg_ctl ? pg_dump read yes, write NO pg_dumpall read yes, write NO pg_resetxlog NO pg_restore yes? pgtcl_*mod YES postgres NO psql YES reindexdb yes? vacuumdb yes? If no such list exists yet, perhaps we can complete the above one, document it, and pass it on to the packagers.
On Thu, Feb 12, 2009 at 04:16:05PM +0200, Peter Eisentraut wrote: > Item Compatible across major versions? > (i.e. the 8.4 version works with 7.4+ server) > ... > ecpg no? It depends on which kind of compatibility you're looking for. The grammar accepted will surely be different. But running a new application with a new ecpglib against an old server works as long as libpq works. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
Peter Eisentraut wrote: > pg_restore yes? > > I don't know how far back pg_restore works, but the reason I have not produced a backport of parallel restore is that the HEAD version works with dumps and servers at least as far back as 8.2 (and I was careful to make sure it supported older dumps). cheers andrew
Peter Eisentraut escreveu: > If no such list exists yet, perhaps we can complete the above one, document > it, and pass it on to the packagers. > Are you suggesting that if an user has 7.4 and install 8.3 then the package will replace psql-7.4 with psql-8.3? It will confuse users more that help them (psql --version ?) and we will have extra effort to maintain the compatibility version list at each binary. IMHO, we shouldn't advise packagers to do it and instead put some efforts in the in-place-upgrade project. -- Euler Taveira de Oliveira http://www.timbira.com/
Euler Taveira de Oliveira wrote: > Peter Eisentraut escreveu: > > If no such list exists yet, perhaps we can complete the above one, document > > it, and pass it on to the packagers. > > > Are you suggesting that if an user has 7.4 and install 8.3 then the package > will replace psql-7.4 with psql-8.3? It will confuse users more that help them > (psql --version ?) and we will have extra effort to maintain the compatibility > version list at each binary. psql is already compatible with old versions. I don't think we should throw away that work by not maintaining it.
Alvaro Herrera escreveu: > Euler Taveira de Oliveira wrote: >> Peter Eisentraut escreveu: >>> If no such list exists yet, perhaps we can complete the above one, document >>> it, and pass it on to the packagers. >>> >> Are you suggesting that if an user has 7.4 and install 8.3 then the package >> will replace psql-7.4 with psql-8.3? It will confuse users more that help them >> (psql --version ?) and we will have extra effort to maintain the compatibility >> version list at each binary. > > psql is already compatible with old versions. I don't think we should > throw away that work by not maintaining it. > I think we shouldn't too. But I think newbie users will be confused when (s)he doesn't find the exact binary version at her/his machine. -- Euler Taveira de Oliveira http://www.timbira.com/
Peter Eisentraut <peter_e@gmx.net> writes:
> I've been examining multi-major-version binary packaging again, and I was
> wondering whether we have a good overview over which pieces of the
> installation are backward compatible (that is, they can be shared between all
> major versions) and which are not. For example, psql 8.4 can now presumably
> be shared between all major versions, so previous schemes to have several
> psqls installed can be simpified.
ISTM that having psql alone be cross-version-compatible will be just
about completely uninteresting to packagers. If we could make *all*
the user-facing executables be cross-version, then we'd be getting
somewhere; it would be possible to install them all in /usr/bin and
just have a version-specific subdirectory under /usr/libexec or
someplace for the rest of the stuff, which users wouldn't need to
have in their PATH anyway.
Looking at your list, it seems the only part of that that might not
be within reach is that pg_dump output from version N typically
doesn't load into server versions < N. pg_dump is complicated enough
without trying to make it handle that too :-(.
The other parts to worry about are libraries (but existing shlib
versioning schemes may be enough for that) and include files.
Not sure what to do with include files.
regards, tom lane
Michael Meskes wrote: > On Thu, Feb 12, 2009 at 04:16:05PM +0200, Peter Eisentraut wrote: >> Item Compatible across major versions? >> (i.e. the 8.4 version works with 7.4+ server) >> ... >> ecpg no? > > It depends on which kind of compatibility you're looking for. The grammar > accepted will surely be different. But running a new application with a new > ecpglib against an old server works as long as libpq works. Will a program built with ecpg 8.4 run against a 7.4 server work the same as the same program built with ecpg 7.4 run against a 7.4 server? (This implies that the program uses only features present in 7.4.)
Euler Taveira de Oliveira wrote: > Alvaro Herrera escreveu: >> Euler Taveira de Oliveira wrote: >>> Peter Eisentraut escreveu: >>>> If no such list exists yet, perhaps we can complete the above one, document >>>> it, and pass it on to the packagers. >>>> >>> Are you suggesting that if an user has 7.4 and install 8.3 then the package >>> will replace psql-7.4 with psql-8.3? It will confuse users more that help them >>> (psql --version ?) and we will have extra effort to maintain the compatibility >>> version list at each binary. >> psql is already compatible with old versions. I don't think we should >> throw away that work by not maintaining it. >> > I think we shouldn't too. But I think newbie users will be confused when (s)he > doesn't find the exact binary version at her/his machine. Newbie users aren't exactly the target audience for a multiversion installation. And the slightly-past-newbie-users might find the hypothetical "this version of psql supports servers 7.4 through 8.4" notice in the man page or version output helpful.
Tom Lane wrote: > ISTM that having psql alone be cross-version-compatible will be just > about completely uninteresting to packagers. If we could make *all* > the user-facing executables be cross-version, then we'd be getting > somewhere; Wel, I'm not so sure about the "completely uninteresting", but in any case the idea right now is to determine and document where we are, then see what's left to do, and then determine whether or how to go there. > Looking at your list, it seems the only part of that that might not > be within reach is that pg_dump output from version N typically > doesn't load into server versions < N. pg_dump is complicated enough > without trying to make it handle that too :-(. Yes, pg_dump certainly appears to be the major blocker. But it might be doable. I assume it would be less than or equal work to making pg_dump read older versions or psql support older versions. I imagine it could be a GSoC project.
Euler Taveira de Oliveira wrote: > IMHO, we shouldn't advise packagers to do it and instead put some efforts in > the in-place-upgrade project. First, packagers are already doing (part of) it. Second, I don't see where this in-place-upgrade is suddenly going to come from. And third, even if you get in-place upgrade working, compatibility in client tools is still useful if you have large farms of serves to manage.
On Fri, Feb 13, 2009 at 10:58:42AM +0200, Peter Eisentraut wrote: > Will a program built with ecpg 8.4 run against a 7.4 server work the > same as the same program built with ecpg 7.4 run against a 7.4 server? > (This implies that the program uses only features present in 7.4.) No, if the program's SQL is 8.4 specific it won't work. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
On Monday 16 February 2009 12:06:55 Michael Meskes wrote: > On Fri, Feb 13, 2009 at 10:58:42AM +0200, Peter Eisentraut wrote: > > Will a program built with ecpg 8.4 run against a 7.4 server work the > > same as the same program built with ecpg 7.4 run against a 7.4 server? > > (This implies that the program uses only features present in 7.4.) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > No, if the program's SQL is 8.4 specific it won't work. But that wasn't the question.
On Mon, Feb 16, 2009 at 12:39:32PM +0200, Peter Eisentraut wrote: > On Monday 16 February 2009 12:06:55 Michael Meskes wrote: > > On Fri, Feb 13, 2009 at 10:58:42AM +0200, Peter Eisentraut wrote: > > > Will a program built with ecpg 8.4 run against a 7.4 server work the > > > same as the same program built with ecpg 7.4 run against a 7.4 server? > > > (This implies that the program uses only features present in 7.4.) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > No, if the program's SQL is 8.4 specific it won't work. > > But that wasn't the question. Oops, I misunderstood. ecpg itself and its libraries do not use anything version related. All conversation runs through libpq and only one SQL statement is issued by the library itself: "select typlen from pg_type where oid=%d and typelem<>0". Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!