Le mar. 27 déc. 2022 à 06:33, qihua wu 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
> diffe
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, qih
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 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
I would like to follow through and experiment with the examples in the
PostgreSQL documentation but find it difficult to compare impacts of
commands without actual working data.
Is there sample data or a default database that correlates with all the
examples in the PostgreSQL documentation ?
Pr
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
