Re: Linux Update Experience

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

In response to

Browse pgsql-general by date

  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