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 )