On 11/05/2019 10:05 PM, Kevin Brannen wrote:
From: rihad <rihad(at)mail(dot)ru>
Hi, all. Why is it normally suggested to stop the server, upgrade it,
then start it? Wouldn't it be easier & quicker to simply upgrade the
package in-place and restart the service? On OSen that allow
modification of currently running binaries, which is most Unix OS, M$
Windows being a notable exception )
That might be possible on a minor upgrade, but quite probably not on a
major version upgrade. I'm reasonably sure I've read that a major
upgrade *can* change underlying data/structures for tables and other
things. I don't think you want version-X writing to the tables on disk
while version-Y writes a new layout to the same files at the same
time. ??
Why would that matter if the server gets restarted after replacing the binaries? Aren't previous version's binaries "hard-wired" into memory while they are running? AFAIK on FreeBSD at least no attempt is made to stop the corresponding server or restart it when a package is upgraded by pkg(8).
We may be talking past each other here a bit...
After you do an upgrade, of course you have to restart the *PG* server or
you won't be using the new code, will you? :)
The manual or others here are more knowledgeable than I, but I believe that
for a "minor" upgrade, you can just swap out the code and restart PG. For
major upgrades, the PG server is going to have to come down as the underlying
files might be changed/transformed during the upgrade, then you start the
PG server when that's done. Check out the -k option as it can significantly
speed up pg_upgrade. You might find it safer to do a "pg_upgrade -c" before
the real upgrade; something to look at. As always on things like this, test
on a non-production machine first.
For us, we always use pg_upgrade even for minor updates because it feels
safer to me. That being said, we rarely do minor updates and just do majors
because upgrading is just hard enough (lots of testing!) we tend to wait and
then jump further. Upgrading is known to take a maintenance window; we just
plan things that way. Your organization may have different needs.
Yeah, but that way you're almost guaranteed to run an unsupported &
vulnerable release for quite some time, until the next major one is ready )
