Re: best practice to patch a postgresql version?

Le mar. 27 déc. 2022 à 06:33, qihua wu <staywithpin(at)gmail(dot)com> a écrit :

> 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.
>
>
If you really want to have different minor releases installed on one
computer, you'll have to compile them, and specify an install directory at
the configure step. See https://www.postgresql.org/docs/15/installation.html
for more information.

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

--
Guillaume.