Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 42894 - Suggestion of use of slots for PostgreSQL
Summary: Suggestion of use of slots for PostgreSQL
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: All All
: Lowest enhancement (vote)
Assignee: PgSQL Bugs
: 199142 (view as bug list)
Depends on:
Reported: 2004-02-25 07:26 UTC by Mark Gibson
Modified: 2008-06-07 20:24 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

Initial plan for slots (postgresql-files.txt,1.96 KB, text/plain)
2004-02-26 08:27 UTC, Mark Gibson
ebuild for PostgreSQL using slots (postgresql-slotted-ebuild.tar.bz2,14.99 KB, application/octet-stream)
2004-03-05 07:24 UTC, Mark Gibson

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Gibson 2004-02-25 07:26:05 UTC
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.
Comment 1 Mark Gibson 2004-02-26 08:27:04 UTC
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 2 Mark Gibson 2004-02-26 08:28:25 UTC
Comment on attachment 26400 [details]
Initial plan for slots

I forgot to mention, the changes to locations are within {}.
Comment 3 Arthur Ward 2004-02-26 09:17:12 UTC
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.
Comment 4 Mark Gibson 2004-03-05 07:24:07 UTC
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.
Comment 5 Masatomo Nakano (RETIRED) gentoo-dev 2004-03-05 07:38:20 UTC
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?
Comment 6 Mark Gibson 2004-03-08 01:05:26 UTC
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?

Comment 7 Peter Fein 2006-01-11 15:22:45 UTC
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.
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2006-07-23 17:06:30 UTC
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. ;)
Comment 9 Peter Fein 2006-07-24 10:42:35 UTC

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...

Comment 10 Kenneth Perry 2006-07-31 09:27:58 UTC 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.
Comment 11 Luca Longinotti (RETIRED) gentoo-dev 2006-09-30 08:51:45 UTC
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.

Comment 12 Luca Longinotti (RETIRED) gentoo-dev 2006-09-30 08:52:32 UTC
Ups, forgot the URL...
Best regards, CHTEKK.

Comment 13 Jakub Moc (RETIRED) gentoo-dev 2007-11-14 19:17:31 UTC
*** Bug 199142 has been marked as a duplicate of this bug. ***
Comment 14 Robert Piasek (RETIRED) gentoo-dev 2008-04-04 12:45:00 UTC
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)
Comment 15 Tiziano Müller (RETIRED) gentoo-dev 2008-04-04 13:51:21 UTC
please check our overlay.
Comment 16 Tiziano Müller (RETIRED) gentoo-dev 2008-06-07 20:24:42 UTC
Done. Finally.