From owner-freebsd-ports@freebsd.org Tue Aug 4 07:54:15 2015 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 101919B2159 for ; Tue, 4 Aug 2015 07:54:15 +0000 (UTC) (envelope-from girgen@pingpong.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EDE30DF for ; Tue, 4 Aug 2015 07:54:14 +0000 (UTC) (envelope-from girgen@pingpong.net) Received: by mailman.ysv.freebsd.org (Postfix) id EB0DD9B2158; Tue, 4 Aug 2015 07:54:14 +0000 (UTC) Delivered-To: ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA90A9B2155 for ; Tue, 4 Aug 2015 07:54:14 +0000 (UTC) (envelope-from girgen@pingpong.net) Received: from mail.pingpong.net (mail.pingpong.net [79.136.116.202]) by mx1.freebsd.org (Postfix) with ESMTP id 05717DD; Tue, 4 Aug 2015 07:54:14 +0000 (UTC) (envelope-from girgen@pingpong.net) Received: from [192.168.1.12] (ppp-2-86-213-26.home.otenet.gr [2.86.213.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pingpong.net (Postfix) with ESMTPSA id 82B4EB3FE; Tue, 4 Aug 2015 09:54:05 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Proposal to fix postgresql package maintainance nightmare From: Palle Girgensohn X-Mailer: iPhone Mail (12H143) In-Reply-To: <20150721120342.GG21594@ivaldir.etoilebsd.net> Date: Tue, 4 Aug 2015 10:54:03 +0300 Cc: Shane Ambler , "pgsql@FreeBSD.org" , "ports@FreeBSD.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7239E352-D053-4EB5-8561-66924C031096@pingpong.net> References: <20150721094627.GD21594@ivaldir.etoilebsd.net> <55AE327F.8040300@ShaneWare.Biz> <20150721120342.GG21594@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 07:54:15 -0000 > 21 jul 2015 kl. 15:03 skrev Baptiste Daroussin : >=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=