Date: Tue, 4 Aug 2015 10:54:03 +0300 From: Palle Girgensohn <girgen@pingpong.net> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: Shane Ambler <FreeBSD@ShaneWare.Biz>, "pgsql@FreeBSD.org" <pgsql@FreeBSD.org>, "ports@FreeBSD.org" <ports@FreeBSD.org> Subject: Re: Proposal to fix postgresql package maintainance nightmare Message-ID: <7239E352-D053-4EB5-8561-66924C031096@pingpong.net> In-Reply-To: <20150721120342.GG21594@ivaldir.etoilebsd.net> References: <20150721094627.GD21594@ivaldir.etoilebsd.net> <55AE327F.8040300@ShaneWare.Biz> <20150721120342.GG21594@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 21 jul 2015 kl. 15:03 skrev Baptiste Daroussin <bapt@FreeBSD.org>: >=20 >> On Tue, Jul 21, 2015 at 09:22:31PM +0930, Shane Ambler wrote: >>> On 21/07/2015 19:16, Baptiste Daroussin wrote: >>> Hi, >>>=20 >>> We do manage a bunch of postgresql servers on FreeBSD, and I really find= the >>> current model of packages postgresql is a nightmare on FreeBSD. >>>=20 >>> Let's first start with the current issues. >>> - Impossible to have tools from both old and new version at the same tim= e (which >>> is necessary to upgrade db and prepare upgrades of db) >>> - Impossible to chose the version we want to run in production without h= aving to >>> rebuild the packages and the whole ports tree with a specific default.= >>> - Nightmare each time a new default version is set in the ports tree. >>=20 >> Sounds like a good plan, I am not a heavy postgresql user but I have >> set the default pg version in make.conf to prevent unexpected new >> versions going in during port updates when I didn't think of doing >> upgrade steps. >>=20 >>> Here is my proposal to fix that. >>>=20 >>> Having one single postgresql-client package always on the latest stable v= ersion >>> (backward compability being very good) providing the client cli tools an= d the >>> libraries (those libraries will be used for everything in the ports tree= >>> needing to talk to postgresql) >>>=20 >>> Have one full postgresql package per supported version upstream self ins= talling >>> itself into let's say: /usr/local/postgresql94 and symlinks all the clie= nt tools >>> to /usr/local/bin suffixed by the version psql94 pg_bla94 etc. >>=20 >> Don't want to start a debate but thought I would mention as food for=20 >> thought -- >>=20 >> I'm not sure of any strong need to have more than one pg client version >> available. The newer client can connect to any older server and I don't >> know of any issues when an old client connects to a newer server. >=20 > That is why I propose only one client for regular users >>=20 >>> That way everything talk to pgsql will only depend on one postgresql-cli= ent >>> packages that will smoothly be upgraded to newer versions. >>>=20 >>> All database administrators will have the ability to chose the productio= n >>> version they do want without having to worry about a default version. >>>=20 >>> They can install multiple version in parallel and deal with upgrade the w= ay they >>> want having access to both versions of the tools of the same time. >>>=20 >>> Any opinion on that change? Any idea one how to make the upgrade path as= >>> transparent as possible for current setup? (beside of course adding an U= PDATING >>> entry) >>=20 >> I think allowing multiple pg server versions is a good idea, this can >> prevent old binary versions being removed before the data update process.= >>=20 >> A new upgrade command could be added so we can do `service postgresql >> upgrade` which tests for existing paths, defines old and new dirs and >> runs pg_upgrade. >>=20 >> The rc script could either add a version postfix to the data dir path >> or test PG_VERSION content to decide if data gets moved to data-old so >> new versions being started won't see older version data. Lack of up to >> date data dirs can lead to "You need to perform an upgrade first." >> Different disk usage (filecount?) for old and new data dir can lead to >> "Have you upgraded your old data?" >>=20 >> I don't think an upgrade step could be added during a port build, it >> would have to be at server start in the rc script. I wouldn't add an >> automatic upgrade step unless it was enabled by the user. >=20 > 100% agree, at first I would not even propose an automatic upgrade mechani= sm I > find it too dangerous by design I would expect admins to do upgrade themse= lves > preparing it etc. >=20 > By upgrade patch I was more thinking when a user will make pkg upgrade and= get > the new scheme I want everything to be safe and smooth (transparent) from w= hat I > already tested this is the case now, but hey maybe someone has figured out= > something that could be wrong. >=20 > Best regards, > Bapt Hi, Sorry for not joining the conversation earlier. Did anything more happen her= e? I did some test work a few years ago to make it possible to have multiple ve= rsions installed in parallel. My approach then was that of lib/pgsqlNN and s= ymlinks for the default version, similar to how macports do it.=20 Reading the discussion in this thread, one of the main goals would be to eas= e dependency management for ports depending on PostgreSQL. My previous appro= ach would not really remedy that problem.=20 Suggesting just one client install is not perfect either, since psql's inter= nal commands, \[a-zA-Z]+, are somewhat linked to the version on the server. T= hough these commands rarely changes, it happens.=20 What is extremely stable, though, is libpq.so.5. And isn't that what most po= rts depend upon? So the best would perhaps be to separate postgresql-libpq that always uses t= he latest version (?) and have postgresqlNN-(client|server|contrib) like now= , except that the client of course is stripped from libpq? I'm not sure how we would handle alpha- and beta versions, but for productio= n versions it would probably work.=20 Thoughts? Palle=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7239E352-D053-4EB5-8561-66924C031096>