If it really is a critical production database, you will have a CAT/UAT
(customer/user acceptance testing) server on which you rigorously run
regression tests on a point release for a month before updating the
production server.
Otherwise, it's a hope-and-pray database.
On 12/26/22 23:33, qihua wu wrote:
Thanks Ron,
But on a critical production database, we need to cut down the downtime as
much as possible. If just remove a version, and then install a new
version, both of them need a downtime. If we can install several versions
on different location, switching version will have a shorter downtime:
just stop the old version and start using the new binary, and we have no
downtime when remove/install a new version.
On Mon, Dec 26, 2022 at 11:54 PM Ron <ronljohnso...@gmail.com> wrote:
Just downgrade the packages if you need to revert to a previous version.
Remove the 14*.5* package, and install the 14*.4* package (because no
one's crazy enough to start with 14.0 in December 2022). You'll have
to explicitly specify the version number.
On 12/26/22 03:29, qihua wu wrote:
We are planning to use postgresq on production, but there is one
question about how to patch a db. We don't want to overwrite the old
version directly, so that we can rollback if the new version has
issues. So we want to install it a different location such as
/home/postgres/14.1 for version 14.1 (all binary should be under 14.1
or sub-fold of 14.1) and /home/postgres/14.0 for 14.0, in this way we
can easily switch between different versions. But apt install on
ubuntu doesn't have the option for a customized location. So what's
the best practice to patch postgres?
--
Born in Arizona, moved to Babylonia.
--
Born in Arizona, moved to Babylonia.
