Date: Wed, 5 Aug 2015 00:29:41 +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: <21E04846-08C2-47FD-8AE7-1AEE47B9FDFA@pingpong.net> In-Reply-To: <20150804091128.GA31243@ivaldir.etoilebsd.net> References: <20150721094627.GD21594@ivaldir.etoilebsd.net> <55AE327F.8040300@ShaneWare.Biz> <20150721120342.GG21594@ivaldir.etoilebsd.net> <7239E352-D053-4EB5-8561-66924C031096@pingpong.net> <20150804091128.GA31243@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 4 aug 2015 kl. 12:11 skrev Baptiste Daroussin <bapt@FreeBSD.org>: >=20 >> On Tue, Aug 04, 2015 at 10:54:03AM +0300, Palle Girgensohn wrote: >>=20 >>=20 >>=20 >>=20 >>>> 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 fi= nd 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 t= ime (which >>>>> is necessary to upgrade db and prepare upgrades of db) >>>>> - Impossible to chose the version we want to run in production without= having 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 stabl= e version >>>>> (backward compability being very good) providing the client cli tools a= nd the >>>>> libraries (those libraries will be used for everything in the ports tr= ee >>>>> needing to talk to postgresql) >>>>>=20 >>>>> Have one full postgresql package per supported version upstream self i= nstalling >>>>> itself into let's say: /usr/local/postgresql94 and symlinks all the cl= ient 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-c= lient >>>>> packages that will smoothly be upgraded to newer versions. >>>>>=20 >>>>> All database administrators will have the ability to chose the product= ion >>>>> version they do want without having to worry about a default version. >>>>>=20 >>>>> They can install multiple version in parallel and deal with upgrade th= e way 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 a= s >>>>> transparent as possible for current setup? (beside of course adding an= UPDATING >>>>> 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 proces= s. >>>>=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 mecha= nism I >>> find it too dangerous by design I would expect admins to do upgrade them= selves >>> preparing it etc. >>>=20 >>> By upgrade patch I was more thinking when a user will make pkg upgrade a= nd get >>> the new scheme I want everything to be safe and smooth (transparent) fro= m what I >>> already tested this is the case now, but hey maybe someone has figured o= ut >>> something that could be wrong. >>>=20 >>> Best regards, >>> Bapt >>=20 >> Hi, >>=20 >> Sorry for not joining the conversation earlier. Did anything more happen h= ere? >=20 > Don't worry I would not have pushed any big change like this without you > reviewing and validating first :) >>=20 >> I did some test work a few years ago to make it possible to have multiple= versions installed in parallel. My approach then was that of lib/pgsqlNN an= d symlinks for the default version, similar to how macports do it.=20 >>=20 >> Reading the discussion in this thread, one of the main goals would be to e= ase dependency management for ports depending on PostgreSQL. My previous app= roach would not really remedy that problem.=20 >>=20 >> Suggesting just one client install is not perfect either, since psql's in= ternal commands, \[a-zA-Z]+, are somewhat linked to the version on the serve= r. Though these commands rarely changes, it happens. >=20 > Yup that is what I figured out. >>=20 >> What is extremely stable, though, is libpq.so.5. And isn't that what most= ports depend upon? >>=20 >> So the best would perhaps be to separate postgresql-libpq that always use= s the latest version (?) and have postgresqlNN-(client|server|contrib) like n= ow, except that the client of course is stripped from libpq? >=20 > Yes that would do the trick. >=20 > I have been busy in other area, but that is still in my target. Fine with m= e if > you want to take over that job, I'll be happy to review/test it. Otherwise= I may > send you a patch when I have something working. >=20 > Best regards, > Bapt I won't be doing much work in August, but after that I may look into this ag= ain. If you have something working before September, you're welcome to send a= patch. If later, better check before you start working so we don't do doubl= e work. :-)=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21E04846-08C2-47FD-8AE7-1AEE47B9FDFA>