On Sat, Nov 23, 2024 at 4:39 PM Bruce Momjian <br...@momjian.us> wrote:
> On Sat, Nov 23, 2024 at 03:24:47PM -0500, Ron Johnson wrote: > > On Sat, Nov 23, 2024 at 1:10 PM Bruce Momjian <br...@momjian.us> wrote: > > [snip] > > > > I have to admit, for this question, we just point people to: > > > > https://www.postgresql.org/support/versioning/ > > > > and say bounce the database server and install the binaries. What I > > have never considered before, and I should have, is the complexity of > > doing this for many remote servers. Can we improve our guidance for > > these cases? > > > > > > What guidance is needed? Even for us, where firewalls block our servers > from > > https://download.postgresql.org, it's as simple as downloading the > relevant RPM > > files once (and that done with a PowerShell script), then patching > thusly: > > > > WinScp PG16.4_RHEL8 dir to each server, and on each server > > $ sudo -iu postgres pg_ctl stop -mfast -wt9999 -D /path/to/data > > $ sudo yum install PG16.4_RHEL8/*rpm > > $ sudo -iu postgres pg_ctl start -wt9999 -D /path/to/data > > > > Those three sudo commands take, at most, three minutes. > > I am thinking more of cases where you have 100+ customers, and you need > to coordinate/connect to each company to perform the upgrade. Doing > that every quarter might be a lot of work, and it might be hard to > justify for every minor release. > Two thoughts: - PGDG publishes release notes. - PowerShell + Putty(*) are a darned powerful combo for automating remote maintenance. *It's more than just a GUI ssh client. -- Death to <Redacted>, and butter sauce. Don't boil me, I'm still alive. <Redacted> lobster!
