Re: Managing major PostgreSQL upgrades

From: Saul Perdomo <saul(dot)perdomo(at)gmail(dot)com>
To: Tiffany Thang <tiffanythang(at)gmail(dot)com>
Cc: Forums postgresql <pgsql-general(at)postgresql(dot)org>
Subject: Re: Managing major PostgreSQL upgrades
Date: 2021-11-16 01:48:14
Message-ID: CAN3jBgF8B+tCM=8466NewDRFjEBikr7iJZmUYMU4W0SEc_F+Fg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hey Tiff,

We're in a similar boat. We currently lean on (mostly custom) ansible
scripting to automate all the repeatable tasks we can, but automation of
major PG version upgrades is something we are yet to tackle -- although we
plan to start this effort in the short term.

Would you mind sharing a bit more about your own current upgrade process?
What's your standard, a dump+restore, a pg_upgrade, or replication-based?
Also if you are able to share any lessons learned (e.g. common pitfalls
you've run into) will all be useful information to identify ahead of time
when drafting an automation strategy.

On Mon., Nov. 15, 2021, 6:45 a.m. Tiffany Thang, <tiffanythang(at)gmail(dot)com>
wrote:

> Hi,
> Every year we spent a lot of time planning and manually performing major
> PostgreSQL upgrade on many of our on-prem and RDS instances. I’m wondering
> if there is a better way of managing these upgrades through automation. Can
> anyone share their experiences?
>
> Thanks.
>
> Tiff
>
>
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chen, Yan-Jack (NSB - CN/Hangzhou) 2021-11-16 05:14:19 RE: PostgreSQL debug log doesn't record whole procedure(from receiving request to sending response)
Previous Message Tom Lane 2021-11-15 22:07:45 Re: pg_restore depending on user functions