Date: Wed, 08 Mar 2017 16:53:37 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 217515] [exp-run] Update PostgreSQL default version to 9.5 Message-ID: <bug-217515-13-tCEWPPWbJV@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-217515-13@https.bugs.freebsd.org/bugzilla/> References: <bug-217515-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217515 --- Comment #15 from Palle Girgensohn <girgen@FreeBSD.org> --- 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217515-13-tCEWPPWbJV>