No restoring to unencrypted PG 17? On Tue, Sep 30, 2025 at 4:23 AM Ashish Mukherjee <[email protected]> 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 <[email protected]> wrote: > >> On Fri, Sep 26, 2025 at 8:16 AM Ashish Mukherjee < >> [email protected]> 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!
