From owner-freebsd-ports@freebsd.org Tue Jul 21 12:03:47 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 C7E559A6DFD for ; Tue, 21 Jul 2015 12:03:47 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) 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 A45CD1B9C for ; Tue, 21 Jul 2015 12:03:47 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A0A809A6DFC; Tue, 21 Jul 2015 12:03:47 +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 A033A9A6DFB for ; Tue, 21 Jul 2015 12:03:47 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 378921B9B; Tue, 21 Jul 2015 12:03:47 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wibud3 with SMTP id ud3so112192980wib.1; Tue, 21 Jul 2015 05:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=CaH6cHXAZbOIk3mY0H/6H+fZYeQjAvrNZNq/BTmbgHg=; b=uUyjITlOrZmTDrcpak4kVOVM8fYnk4SEzlh1eq3yZ0jlssWB0Fq3d6nplRk7DGa2eW cMiYIaXkWt5PGZB/pOM7K5MKbDFasamdZzZxtOOtzOd/MOTgCT8y9BSTtcjdbABfM8ic LkqG8WrGcKbdZuymnXHAgygiVLWaMzQbmGQFzw1pqv6K9rrX4m3mAHopgCVC/Wzv26F/ LWPsrd7n/By0QDVavWRKbZ7Nfb/jKEmXoDMpT3o0Wtk2nuJ4jvkH4N2SSS1y66ZgF9GN XPbqprOeifDJP5RlYc3ycxk3wBZn/aL5d4EX2hEpJDBx+Lg3JqyPy20/RhVhJv+y53j0 7fCw== X-Received: by 10.180.77.68 with SMTP id q4mr29542063wiw.22.1437480225675; Tue, 21 Jul 2015 05:03:45 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id fa8sm16521554wib.14.2015.07.21.05.03.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jul 2015 05:03:44 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 21 Jul 2015 14:03:42 +0200 From: Baptiste Daroussin To: Shane Ambler Cc: pgsql@FreeBSD.org, ports@FreeBSD.org Subject: Re: Proposal to fix postgresql package maintainance nightmare Message-ID: <20150721120342.GG21594@ivaldir.etoilebsd.net> References: <20150721094627.GD21594@ivaldir.etoilebsd.net> <55AE327F.8040300@ShaneWare.Biz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WkfBGePaEyrk4zXB" Content-Disposition: inline In-Reply-To: <55AE327F.8040300@ShaneWare.Biz> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 21 Jul 2015 12:03:48 -0000 --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--