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 *
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 |