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