Re: best practice to patch a postgresql version?

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 <ronljohnsonjr(at)gmail(dot)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.