Re: Downgrade pgsql 17 to pgsql 12 question

No restoring to unencrypted PG 17?

On Tue, Sep 30, 2025 at 4: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
>>
>>

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!