From owner-freebsd-ports-bugs@freebsd.org Wed Mar 8 16:53:38 2017 Return-Path: Delivered-To: freebsd-ports-bugs@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 855C7D0153C for ; Wed, 8 Mar 2017 16:53:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B54DC1B for ; Wed, 8 Mar 2017 16:53:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v28GrbwW002958 for ; Wed, 8 Mar 2017 16:53:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 217515] [exp-run] Update PostgreSQL default version to 9.5 Date: Wed, 08 Mar 2017 16:53:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Ports Framework X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: girgen@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: portmgr@FreeBSD.org X-Bugzilla-Flags: exp-run? X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 16:53:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217515 --- Comment #15 from Palle Girgensohn --- Created attachment 180642 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D180642&action= =3Dedit simple script to build a temporay postgresql server in prepare for a pg_upg= rade Hi, Great discussion!=20 As stated several times in this thread, automatic upgrade is not a good ide= a. > Best way would be to allow installation of two different versions, which = would enable pg_migrate usage. But this need PostgreSQL 9.6, which will bre= ak things through the renamed username. The change of username was made after many requests. I would have preferred= to have the same UID for pgsql and postgres, but this was not supported by the ports infrastructure and I did not feel inclined to add support for it. In hindsight, perhaps that was a bad decision. It is what it is now, I guess. As you probably understand, the reason for not updating the default version= of PostgreSQL in the ports tree for such a painfully long time, is just this problem of how to help our users update their databases and keep them out of trouble. My aim is to break out libpq as a separate package and let all client side ports depend on that, and let libpq always install the latest version. libpq has been stable since 84 IIRC. I have discussed this with the pgsql package= rs and they seem to agree that this is a good path. It is similar to what debi= an does, although they do a lot more and have their own tools, some of which I don't particularly fancy. Anyway, this would allow parallel server packages installed, and it would be a great feature. Until then, a `pkg upgrade` would probably lead to conflicts if postgresql93-server is "manually" installed (as opposed to by dependency) w= hen some client port using postgresql-client wants to update and depends on postgresql95-client. Not sure exactly what would happen? How do we best approach this? Speed up the creation of the separate port for libpq? Other suggestions? As for support for pg_upgrade with the current infrastructure, I used a sim= ple script to build an extra server in /var/tmp to use during the upgrade. I he= lped som ppl who asked for support directly to pgsql@ with that script [enclosed here, FWIW]. Maybe it is a too error prone process, but I do not really see= the need for chroot:ing, perhaps you could elaborate on your thoughts about alternative routes? > And because nobody on pgsql@ wants to take a day to figure out how to do = it correctly. This is only partly true. It is not a simple problem, I have spent time pondering how to do this, and my take is the above, "liberating" libpq. It = will take more tahn a day, though... :( Palle --=20 You are receiving this mail because: You are on the CC list for the bug.=