Thanks for the reply.
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.
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 Fri, Mar 8, 2024 at 11:28 AM Yogesh Sharma <yogesh.sharma@xxxxxxxxxxxxxxxxx> wrote:
Greetings,
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
