Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jul 2015 14:03:42 +0200
From:      Baptiste Daroussin <bapt@FreeBSD.org>
To:        Shane Ambler <FreeBSD@ShaneWare.Biz>
Cc:        pgsql@FreeBSD.org, ports@FreeBSD.org
Subject:   Re: Proposal to fix postgresql package maintainance nightmare
Message-ID:  <20150721120342.GG21594@ivaldir.etoilebsd.net>
In-Reply-To: <55AE327F.8040300@ShaneWare.Biz>
References:  <20150721094627.GD21594@ivaldir.etoilebsd.net> <55AE327F.8040300@ShaneWare.Biz>

next in thread | previous in thread | raw e-mail | index | archive | help

--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150721120342.GG21594>