[Bug 217515] [exp-run] Update PostgreSQL default version to 9.5

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217515

--- Comment #15 from Palle Girgensohn <girgen at FreeBSD.org> ---
Created attachment 180642
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180642&action=edit
simple script to build a temporay postgresql server in prepare for a pg_upgrade

Hi,

Great discussion! 

As stated several times in this thread, automatic upgrade is not a good idea.

> 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 break 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 packagers
and they seem to agree that this is a good path. It is similar to what debian
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) when
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 simple
script to build an extra server in /var/tmp to use during the upgrade. I helped
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.