Date: Tue, 21 Jul 2015 14:03:42 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Shane Ambler <FreeBSD@ShaneWare.Biz> Cc: pgsql@FreeBSD.org, ports@FreeBSD.org Subject: Re: Proposal to fix postgresql package maintainance nightmare Message-ID: <20150721120342.GG21594@ivaldir.etoilebsd.net> In-Reply-To: <55AE327F.8040300@ShaneWare.Biz> References: <20150721094627.GD21594@ivaldir.etoilebsd.net> <55AE327F.8040300@ShaneWare.Biz>
next in thread | previous in thread | raw e-mail | index | archive | help
--WkfBGePaEyrk4zXB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 21, 2015 at 09:22:31PM +0930, Shane Ambler wrote: > On 21/07/2015 19:16, Baptiste Daroussin wrote: > > Hi, > > > > We do manage a bunch of postgresql servers on FreeBSD, and I really fin= d the > > current model of packages postgresql is a nightmare on FreeBSD. > > > > Let's first start with the current issues. > > - Impossible to have tools from both old and new version at the same ti= me (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 defaul= t. > > - 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. > > > > Having one single postgresql-client package always on the latest stable= 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 tree > > needing to talk to postgresql) > > > > Have one full postgresql package per supported version upstream self in= stalling > > itself into let's say: /usr/local/postgresql94 and symlinks all the cli= ent 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. That is why I propose only one client for regular users >=20 > > That way everything talk to pgsql will only depend on one postgresql-cl= ient > > packages that will smoothly be upgraded to newer versions. > > > > All database administrators will have the ability to chose the producti= on > > version they do want without having to worry about a default version. > > > > They can install multiple version in parallel and deal with upgrade the= way they > > want having access to both versions of the tools of the same time. > > > > 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 = 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 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. 100% agree, at first I would not even propose an automatic upgrade mechanis= m I find it too dangerous by design I would expect admins to do upgrade themsel= ves preparing it etc. 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. Best regards, Bapt --WkfBGePaEyrk4zXB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlWuNR4ACgkQ8kTtMUmk6Eyi9QCdG6hvFs8VM8tSLZL2Q+KI1BUP dvcAoKz1PWdeTwRMgIbzV9PsVE7dUjJm =hGG8 -----END PGP SIGNATURE----- --WkfBGePaEyrk4zXB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150721120342.GG21594>