Thread: Upgrade procedure
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 ) Thanks.
On Wed, Oct 30, 2019 at 6:00 PM rihad <rihad@mail.ru> wrote: > 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 ) Not sure exactly why, and whether postmaster protects itself from this, but in many years of using linux, which supports it, I've encountered my share of (minor) problems when doing that, typically due to the program not having loaded all the modules it can use ( firefox is a classic for me, as I have it normally open while I do my background updates, nothing a restart does not solve, but I would get nervous doing that to the database ). That being said, I've upgraded my TEST servers without stopping them ( although lately the upgrade scripts do a restart at the end ), but for production I prefer to download everything and prepare as much as I can and do a stop-finish upgrade-start, the last ( file extracting ) phase is normally much faster than the server restart machinery, so no much is gained by doing it in paralell. And other thing, MODIFICATION of currently running binaries is BAD, and IIRC many OS use them for paging and will not be happy ( maybe in these days they transparently switch to normal swap ). What you normally want is unlinking and replacing, modification of the names aka dir contents (not being able to do this is one of my strongest dislikes of windows, it makes so many things so much simpler ). Francisco Olarte.
>From: rihad <rihad@mail.ru> >Hi, all. Why is it normally suggested to stop the server, upgrade it, then start it? Wouldn't it be easier & quicker tosimply 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 readthat a major upgrade *can* change underlying data/structures for tables and other things. I don't think you want version-Xwriting to the tables on disk while version-Y writes a new layout to the same files at the same time. 😊 As always, see the fine manual, especially the part on upgrades and release notes. 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.
> >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).
>> >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.
On Tue, 5 Nov 2019, Kevin Brannen wrote: > 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, ... Files might change even with a minor upgrade. The few seconds it takes to stop, upgrade, and restart the system prevents all errors due to someone/something accessing the database while it's being upgraded. Rich
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 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. > 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 )
>> 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 nextmajor one is ready ) If we ran into a true bug that affected us, we'd upgrade sooner. Thankfully, the PG team is great about putting out quality software with a low bug rate. Running a few minor versions back from the current is OK for us; we're always on a supported major version (so we could upgrade to the current minor version if really required). This is an organizational decision based on where it's better to spend time and effort. OTOH, the better partitioning of v12 is a feature that will get us to upgrade sooner. :) As for security, we run in a very protected environment. If we are compromised, it'll be by an inside person and there's really no tech defense against that. Upgrading the Pg software isn't all that hard, we even have it automated. The upgrade process for our application is what's so hard -- again, lots of testing/man-hours required. 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.