Due to the incompatibilities between major versions of PostgreSQL (eg. 7.3 -> 7.4), wouldn't it make sense to use the slot facility provided by portage (like KDE does). So PostgreSQL 7.4.x has SLOT="7.4", and the next release 7.5.x has SLOT="7.5", this would provide a much easier route for major version upgrades. I'd try this myself, but unfortunately I don't really have the time at present, so I'm making the suggestion here.
Created attachment 26400 [details] Initial plan for slots I've put together an initial plan for relocating files to support the slotting of PostgreSQL. Suggestions and corrections are very much welcome. Can anyone advise of any issues I need to be aware of? I'm going try this out next week.
Comment on attachment 26400 [details] Initial plan for slots I forgot to mention, the changes to locations are within {}.
I don't know squat about implementing slots, but this would be very useful for testing apps on new versions before migrating to it for production work. This gets my vote as a worthwhile thing to do.
Created attachment 26901 [details] ebuild for PostgreSQL using slots This is my first attempt at a slotted ebuild for PostgreSQL. I've managed to emerge both 7.3.5 and 7.4.1 on the same machine, and run them in parallel (7.3 port: 5432, 7.4 port: 5433). Only tested with the following USE flags so far: -doc -java -libg++ -nls +pam -perl -pg-hier -pg-intdatetime -pg-vacuumdelay -python +readline +ssl -tcltk +zlib But I managed to create a small test db on 7.3.6 and migrate it over to 7.4.1 using: /usr/postgresql/7.4/bin/pg_dumpall -p 5432 | \ /usr/postgresql/7.4/bin/psql -d template1 -p 5433 -a Please let me know how you get on if you try this out. Cheers, Mark.
Hi mark, It looks great! I'm going to test your ebuilds. If there is no problems i'll put it to portage tree as masked(package.mask) version first. have you tested if packages which depend on the slotted PostgreSQL work well?
I have tested literally as much as described above, I thought it best best to post the ebuilds for feedback before proceeding any further. So I haven't tried any PostgreSQL dependents yet. But they should be using 'pg_config' to find the installation info. I think we will need a config script, like gcc_config/java_config, that allows selection of default server (postmaster, pg_config etc.) and clients (psql, pg_dump etc.). Should we do that via shell vars (PATH,LDPATH etc.) in env.d or by making symlinks from /usr/bin etc.? Also, I'm not sure what we should do with 'nls' support. Any idea how to find all packages that depend on PostgreSQL? I think that ideally the ebuild should be split into separate server/client ebuilds, as the clients don't really need to be slotted, do you think this would be practical?
Lemme breathe some life back in to this ticket: This would be HUGELY helpful. For those of us running even moderately-available PG servers, it's impossible to upgrade on a single box. A dump/restore can take several hours (if not days), which is an unacceptably long outage for many (most?) folks. The only current approach I can think of (in the absence of SLOTs) is to set up a backup server running the higher version, replicate data to it, switch clients, upgrade the original server and replicate back. Needless to say, this is a pain and potentially expensive (gotta buy that second server). With SLOTs, it'd be possible to do this all on one box with a single PG restart from the client's perspective.
Uhm... We've done this w/ mysql and people ranted that much that it's been removed again from portage very fast. You'd better reconsider this. ;)
Jakub, This seems like the situation SLOTs are intended for - multiple versions of a package that can happily exist side-by-side. I've described a use case where SLOT support would save considerable headache and expense. Can you suggest an alternate solution? I'm not familiar with the MySQL situation at all - could you provide a link to the relevant discussion, ticket etc? An explanation beyond 'MySQL users didn't like SLOTs' would be appreciated. This is a Postgres bug after all... Thanks.
https://forums.gentoo.org/viewtopic-t-438557.html is the slotted mySQL argument. Personally, I see the advantages of the slotted install, biggest drawback i see is ending up with multiple servers because of forgetting the unemerge the old one after you update.
UPDATE: We're working on this in the PostgreSQL Project Overlay [1], it's coming along nicely but don't use it yet, it installs, but nothing else will find the pgsql headers, bins etc. ;) I've just read Mark Gibson's initial plans for it, and what we've been cooking up in the overlay is largely similar. Just fyi: man-pages too need slotting, bins will be put into /usr/bin/$binname-$SLOT, locales do indeed need slotting too, libs will be versioned with the actual pgsql version (not .so.3.1, but fex. .so.8.0 and so on), and includes will go to /usr/include/postgresql/pgsql-$SLOT/ (and/or libpq-$SLOT for libpq, we still have to finalize and check this throughly). Best regards, CHTEKK. [1]
Ups, forgot the URL... Best regards, CHTEKK. [1] http://overlays.gentoo.org/proj/postgresql/timeline
*** Bug 199142 has been marked as a duplicate of this bug. ***
ok its a VERY old bug, but idea behind it is good. Personally I run 3 different postgres versions on my development server and would love to be able to use ebuilds for all of them. I can understand that might also cause lots of problems (like mentioned MySQL slots). Is there any chance SLOT can be determinated by USE flag? lets say if flag "sloted" is enabled than SLOT=current_ver else SLOT=0 ? (well it's just a thought)
please check our overlay.
Done. Finally.
