From: | Christoph Moench-Tegeder <cmt(at)burggraben(dot)net> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Linux Update Experience |
Date: | 2020-05-29 09:56:49 |
Message-ID: | 20200529095649.GB2410@elch.exwg.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
## Peter J. Holzer (hjp-pgsql(at)hjp(dot)at):
> * Update frequently. That reduces the risk of needing a package which
> has since been deleted from a repo, but more importantly it makes it
> easier to pinpoint the cause of a conflict.
This. Plus: make sure you can re-create any machine in a fully deterministic
manner - that way, you can easily create a test environment to match
production (minus RAM/CPU/storage) for testing upgrades beforehand.
Rationale: experience shows that using Test as "first stage" and carrying
changes forward to Production results in a "contaminated" test environment;
before long, results of failed experiments have accumulated on Test,
Production and Test are diverging, and at that point Test has lost it's
purpose.
(For some people, that's a point for containerization: you don't change
a running container, but package a new one. Other environments have so
much Production with all the redundancy etc that they can "test in
production" and just scrap-and-replace failed tests, but that's not an
option if you have just a handful of systems.)
Regards,
Christoph
--
Spare Space
From | Date | Subject | |
---|---|---|---|
Next Message | Frank Millman | 2020-05-29 12:14:05 | Re: Slow SELECT |
Previous Message | brajmohan saxena | 2020-05-29 07:58:06 | PG server process can keep some info of backend |