RE: Upgrade procedure - Mailing list pgsql-general

>> >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
serveror 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.

HTH,
Kevin
This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential
information.If you are not the intended recipient, or a person responsible for delivering it to the intended recipient,
youare hereby notified that any disclosure, distribution, review, copy or use of any of the information contained in or
attachedto this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately
notifyus by reply e-mail, and destroy the original transmission and its attachments without reading them or saving them
todisk. Thank you.