When you say "dump/restore" do you mean pg_dump then running the resulting SQL into the destination DB? I like the replication option myself best (min downtime), especially as we use a DB alias for connections. But I don't think I'll be able to sell that to the IT group.
Regarding the safety of running a "drop extension plperlu cascade" on the v11.5, would you consider that to be safe GIVEN that there are no plperlu procs that it will affect? I need to be able to tell IT that I'm not the only one who thinks that it's safe.
On 3/6/24 19:19, David Gauthier wrote: > Hi: > I'm a PG user in a big corp with an IT dept that administers a PG > server/instance that I use. It's an old install, v11.5, and we need > to upgrade to v15.3. They want to bring the upgraded DB up on a new > linux vm which has OS upgrades of its own. So it's a move AND an > upgrade. There are 2 concerns.... > > First has to do with a jump from 11.5 - 15.3 ? Is it safe to do this > given so many major intermediate versions being skipped ?
Generally speaking, it is safe from database point of view but you have to verify that application is working as expected with PostgreSQL 15, driver update, any query performance issues, any deprecate features in use, collation differences, and performance verification, etc.
PostgreSQL supports dump/restore (slow and longer downtime), binary upgrade using pg_upgrade (faster and low downtime), and logical replication (complex and least downtime). Since OS upgrade is also part of the equation, dump/restore or logical are better candidates. Due to OS collation difference I would avoid binary upgrade path.
-- Kind Regards, Yogesh Sharma PostgreSQL, Linux, and Networking Expert Open Source Enthusiast and Advocate PostgreSQL Contributors Team @ RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
