Re: Downgrade pgsql 17 to pgsql 12 question

From: Pavan Kumar <pavan(dot)dba27(at)gmail(dot)com>
To: Ashish Mukherjee <ashish(dot)mukherjee(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Downgrade pgsql 17 to pgsql 12 question
Date: 2025-10-03 15:15:58
Message-ID: CA+M0sHEjWjpqAxU_iW=Da5jhjXLi1yeWYQn0Nwy47oFWC2LjoA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello Ashish Mukherjee,

Did you get a chance to disable JIT related parameters after PG 17
upgrade ?

If your database size in TB , try to consider pglogical bi directional
replication. you will have 17.x version and 12.x version. if you ran in to
any issue you can always switch back to old version.
I am not sure TDE supported bi directional replication

On Tue, Sep 30, 2025 at 3:23 AM Ashish Mukherjee <ashish(dot)mukherjee(at)gmail(dot)com>
wrote:

> Thank you all for your inputs.
>
> Well, Percona TDE was leading to the queries being very inefficient / slow
> after upgrading to pgsql 17. Explain analyze shows that query planning time
> shoots up crazily. A decision was taken to go back to pgsql 12, which
> worked out fine as there was no incompatibility. I restored from the binary
> dump with the -j option, as our database is huge. I completely agree that
> downgrade is not a good option but a pragmatic one under the circumstances.
>
> Now the consideration is to use some other encryption option for the
> database which will work fine on pgsql 17. Cybertec's technology is one
> route, the other is EDB. I am happy to hear experiences of folks here with
> pgsql encryption options for v17 on large databases (2.5T in our case).
>
> On Mon, Sep 29, 2025 at 5:10 AM Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>
>> On Fri, Sep 26, 2025 at 8:16 AM Ashish Mukherjee <
>> ashish(dot)mukherjee(at)gmail(dot)com> wrote:
>>
>>> Hello,
>>>
>>> I have a strange requirement to downgrade from pgsql 17 to pgsql 12.
>>> This is because we found in production certain incompatibilities between
>>> both versions for our database. It should have been caught in testing but
>>> was not.
>>>
>>
>> Agree with others that snap downgrade is not necessarily a good choice
>> here. Either way, if I were in your shoes, I'd be loading a plain text
>> dump, maybe with some light massaging to strip out some compatibility
>> issues.
>>
>> Can you let us know what the hang up is? Version upgrades these days are
>> usually pretty painless except for some performance issues, unless you have
>> some unusual situations, for example, exotic extensions.
>>
>> merlin
>>
>>

--

*Regards,#! Pavan Kumar----------------------------------------------*-
*Sr. Database Administrator..!*
*NEXT GENERATION PROFESSIONALS, LLC*
*Cell # 267-799-3182 # pavan.dba27 (Gtalk) *
*India # 9000459083*

*Take Risks; if you win, you will be very happy. If you lose you will be
Wise *

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Mathieu Pellerin 2025-10-05 09:19:01 Re: Client/server certificates verification support on Android platform
Previous Message Nathan Bossart 2025-10-02 17:37:44 Re: Clarification on Role Access Rights to Table Indexes