>> >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. 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, you are hereby notified that any disclosure, distribution, review, copy or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify us by reply e-mail, and destroy the original transmission and its attachments without reading them or saving them to disk. Thank you.
