Date: Tue, 4 Aug 2015 11:11:29 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Palle Girgensohn <girgen@pingpong.net> 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: <20150804091128.GA31243@ivaldir.etoilebsd.net> In-Reply-To: <7239E352-D053-4EB5-8561-66924C031096@pingpong.net> References: <20150721094627.GD21594@ivaldir.etoilebsd.net> <55AE327F.8040300@ShaneWare.Biz> <20150721120342.GG21594@ivaldir.etoilebsd.net> <7239E352-D053-4EB5-8561-66924C031096@pingpong.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 f= ind 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 = time (which > >>> is necessary to upgrade db and prepare upgrades of db) > >>> - Impossible to chose the version we want to run in production withou= t having to > >>> rebuild the packages and the whole ports tree with a specific defau= lt. > >>> - 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 stab= le version > >>> (backward compability being very good) providing the client cli tools= and the > >>> libraries (those libraries will be used for everything in the ports t= ree > >>> needing to talk to postgresql) > >>>=20 > >>> Have one full postgresql package per supported version upstream self = installing > >>> itself into let's say: /usr/local/postgresql94 and symlinks all the c= lient 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-= client > >>> packages that will smoothly be upgraded to newer versions. > >>>=20 > >>> All database administrators will have the ability to chose the produc= tion > >>> version they do want without having to worry about a default version. > >>>=20 > >>> They can install multiple version in parallel and deal with upgrade t= he 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= as > >>> transparent as possible for current setup? (beside of course adding a= n 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 proce= ss. > >>=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 mech= anism I > > find it too dangerous by design I would expect admins to do upgrade the= mselves > > 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) fr= om what I > > already tested this is the case now, but hey maybe someone has figured = out > > something that could be wrong. > >=20 > > Best regards, > > Bapt >=20 > Hi, >=20 > Sorry for not joining the conversation earlier. Did anything more happen = here? 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 a= nd 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 = ease dependency management for ports depending on PostgreSQL. My previous a= pproach 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 serv= er. 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= now, except that the client of course is stripped from libpq? Yes that would do the trick. 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. Best regards, Bapt --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlXAgcAACgkQ8kTtMUmk6Ex3WwCdGgcuSNj/vDcKCI+/CCTw6lTd SBgAnjf9GnnClQ2rOdV1ONEb+BI4ph1M =u7k6 -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150804091128.GA31243>