Search Postgresql Archives

Re: v11.5- v15.3 upgrade (linux)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/8/24 09:09, Adrian Klaver wrote:
On 3/8/24 08:57, David Gauthier wrote:
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.

You said the dump/restore has been tested.

How long did that take?


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.

BEGIN;

DROP LANGUAGE plperlu;

Arrgh. That should be

DROP EXTENSION plperlu;


ROLLBACK;

See if the above complains about anything depending on it.

If not:

DROP EXTENSION plperlu;




On Fri, Mar 8, 2024 at 11:28 AM Yogesh Sharma <yogesh.sharma@xxxxxxxxxxxxxxxxx <mailto: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 <https://aws.amazon.com>



--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux