Thanks.
On Fri, Mar 8, 2024 at 12:12 PM Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
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
