Upgrading PostgreSQL... can I do it "live" with yum?

I'm running PostgreSQL v9.3.4 on Oracle Linux v6.7 (aka CentOS, aka RedHat).  I would like to upgrade to the new PostgreSQL version v9.3.5, and one of my fellow DBA's posed an interesting question that could save us a few minutes of downtime:

QUESTION: If we leave the database running and do a "yum update", won't the old binaries that are in use be OK (because the filesystem won't release them until the file handle is closed) so that we can minimize downtime to simply a stop/start?

So the upgrade process would be:

yum update
pg_ctl restart

I think this could be potentially dangerous, as what if v9.3.4 is running and then needs to re-spawn something... it would grab the v9.3.5 binary.  I think that the only safe way is:

pg_ctl stop
yum update
pg_ctl start

Sure, we could install the new binaries into a different directory like what happens during major releases (e.g. 9.0 -> 9.4)... but that seems like too much hassle for a point release and a few minutes of downtime saved.

Sophia PaterakisAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Nick UpsonPrincipal Operations EngineerCommented:
I can't answer you speicifially but as a longtime dba and sysadmin I wouldn't even consider it. simple cost/benefit = save maybe 5 mins vs corrupt database, no contest
If you want to minimize downtime and risk I would consider downloading the rpms locally or hosting the repository locally as this would cut down the time significantly with a yum update.

Stopping the database is the safest way. However, I have not run into issue updating postgres while it is running. It is like fueling your car while the engine is running.
Sophia PaterakisAuthor Commented:
Thanks NickUpson and Mazdajai.  I think safest is best, but I'm intrigued by your answer Mazdajai... is this something you regularly do?  Update the binaries whilst it's running?
SolarWinds® VoIP and Network Quality Manager(VNQM)

WAN and VoIP monitoring tools that can help with troubleshooting via an intuitive web interface. Review quality of service data, including jitter, latency, packet loss, and MOS. Troubleshoot call performance and correlate call issues with WAN performance for Cisco and Avaya calls

We patch every month on 50+ database servers. We take a cold snapshot before yum update.

Keep in mind that updating the package is changing the files on the disk, it does not take effective until restarting the service because it is running in memory.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Sophia PaterakisAuthor Commented:
Thanks gang.  I think I've convinced everyone that the small extra downtime is worth it to eliminate the risk, but it's intriguing to find that it can be done.
yum update  will condrestart all init.d scripts that are in package.
there is no need for extra downtime for extra restart.
you can run needs-restarting from yum-utils to see if all restarted ok (e.g sshd will not restart on opensl upgrade)

about corrupting database by changing binaries it is plain imagination . there is no such problem.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.