Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v3a9b-000fNP-VO for pgsql-general@arkaria.postgresql.org; Tue, 30 Sep 2025 13:12:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v3a9Z-009sPl-Il for pgsql-general@arkaria.postgresql.org; Tue, 30 Sep 2025 13:12:26 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v3a9Z-009sPc-3p for pgsql-general@lists.postgresql.org; Tue, 30 Sep 2025 13:12:25 +0000 Received: from mail-ot1-x334.google.com ([2607:f8b0:4864:20::334]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v3a9X-000hhn-0p for pgsql-general@postgresql.org; Tue, 30 Sep 2025 13:12:24 +0000 Received: by mail-ot1-x334.google.com with SMTP id 46e09a7af769-7b4f7a855baso1949231a34.3 for ; Tue, 30 Sep 2025 06:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759237942; x=1759842742; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Pipt/sQmWXeKEPdj4yOiYcw4QLavdYaEz0c5WONmhB0=; b=hlqJ0+Ok3o2dxSdry4OgtJBt9wzmnghvBnUY3ie8MUW5v+9DCD0dEFRRhP+sqpe2cj EhBWHzuAoToni6PNTILkLmvQKLO7o6LG3FyvbxEFqgU3bOUqZv1ZDHCEm2ArGMpBhouG 0wj1tXvc1JJCM7rnK0oMjJRA6sIyPnyZ3BQbGugOnDICHVTOBBy9AZZaehFWNM3Dnc4M RsyahhD7SxDqMB00po4Iqwt2OKF2K1K81DKmxEQWPW30VdRoeb/W/yplIzi7XlM0KHK+ R9xJz+M1KFKIeJBtBXtnW4amnL/qtHMX6o2jBBcua8BN+O2+4SrV/CUvDgrASJ3pLUip LAHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759237942; x=1759842742; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Pipt/sQmWXeKEPdj4yOiYcw4QLavdYaEz0c5WONmhB0=; b=CJH8+KLkL2ZAem944iO9QwwgUgfnRF6Buih+w4OFAkdqnT7nFt+3C7JMxSMOLem9/r ECedzWHkm9kIqeYVHXlzkb6DK/2GjEg7Nb6aTcz/whTVgIzRDVbf/fzuTNMTrIDTIkVE hHtARyN3JaAymKE5gKO8A1Z8JThWriavyl5pKrtlC7aI5jdec3OO+i7Ci+t47Nlw32Zu 6qvXHEe4urVXfmFG2yJSluYGcyU47R6ND1w5A94djtp6NaPe8J6+Pyqrmxo3bH1tzI/G 30w6JmVelIBsiUffTLmVa9/7T2NLrCwk0TWzAZ+ViyzNXeFlmvy6rMXK1Mh8i24FKJIj 0uww== X-Gm-Message-State: AOJu0YztMjio4SsVDtwXxf3oFOMahOXRwEiVlyNvt2M4kmV8VRvszyVI s3aeQuoQnsNX1g2bKAnVY8kbjB62IFCC6D5hlWlp1VrxjAeFqjXq3SWG+lwrBMJ869+iIj8yHT3 xRgnGhqRkWxXrODGZgGtl7CWfKhTgYfp74Q== X-Gm-Gg: ASbGncud+FiO6Ewaut6g1FUFrttqaOHLTUlEACSwiJFQ1tHfAvmlauUZrTeSVlUB20P 1zCNdbZF76kNbyKzOXw1MK5pS7zxu8TKqXISkJGR6PXJ6ATrIe1+xv2WoL4IMiOC1LZQqGXd0EG /YwYUka6kP/9rSiVCHh761ddfr37J2HHtCvx0zee8/t1SLPVyYQkUirfP/FaodjxF2bzuvGnJ21 Jqr925yeWdZRijQZc5xSbGztVul/YVdSxXLHEY1D+0= X-Google-Smtp-Source: AGHT+IFo+FnvIo6XOuAGvoJfBZhvLyRCXFaYeqi2Sc/Sy6BYdR1RHtz15/2yfRHDNrieFhpmNp9ah7Y0JeEEdrKVIFM= X-Received: by 2002:a05:6808:229e:b0:43f:2642:5c5a with SMTP id 5614622812f47-43f963d9feamr1639878b6e.8.1759237942603; Tue, 30 Sep 2025 06:12:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Tue, 30 Sep 2025 09:12:11 -0400 X-Gm-Features: AS18NWBiD9uCkGb-MKPqCvmYzAsEmqEdf8F2qPUyxYt25nzbRwhJ7A-iYpEsJuc Message-ID: Subject: Re: Downgrade pgsql 17 to pgsql 12 question To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000a4f55406400480fb" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a4f55406400480fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No restoring to unencrypted PG 17? On Tue, Sep 30, 2025 at 4:23=E2=80=AFAM Ashish Mukherjee wrote: > Thank you all for your inputs. > > Well, Percona TDE was leading to the queries being very inefficient / slo= w > after upgrading to pgsql 17. Explain analyze shows that query planning ti= me > 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 bina= ry > 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 circumstance= s. > > 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 wit= h > pgsql encryption options for v17 on large databases (2.5T in our case). > > On Mon, Sep 29, 2025 at 5:10=E2=80=AFAM Merlin Moncure wrote: > >> On Fri, Sep 26, 2025 at 8:16=E2=80=AFAM Ashish Mukherjee < >> ashish.mukherjee@gmail.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 betwee= n >>> both versions for our database. It should have been caught in testing b= ut >>> 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 ar= e >> usually pretty painless except for some performance issues, unless you h= ave >> some unusual situations, for example, exotic extensions. >> >> merlin >> >> --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000a4f55406400480fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

No restoring to unencrypte= d PG 17?

On Tue, Sep 30, 2= 025 at 4:23=E2=80=AFAM Ashish Mukherjee <ashish.mukherjee@gmail.com> wrote:
Thank you all for your inputs.

Well, Percona TDE was leading to the queries being very inefficient / sl= ow after upgrading to pgsql 17. Explain analyze shows that query planning t= ime shoots up crazily. A decision was taken to go back to pgsql 12, which w= orked 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 d= owngrade is not a good option but a pragmatic one under the circumstances.= =C2=A0

Now the consideration is to use some other = encryption option for the database which will work fine on pgsql 17. Cybert= ec's technology is one route, the other is EDB. I am happy to hear expe= riences of folks here with pgsql encryption options for v17 on large databa= ses (2.5T in our case).

On Mon, Sep 29, 2025 at 5:10=E2=80=AFAM Merli= n Moncure <mmonc= ure@gmail.com> wrote:
On Fri, Sep 26, 2025 at 8:16= =E2=80=AFAM Ashish Mukherjee <ashish.mukherjee@gmail.com> wrote:
Hello,

I have a strange requirement to down= grade from pgsql 17 to pgsql 12. This is because we found in production cer= tain incompatibilities=C2=A0between both versions for our database. It shou= ld have been caught in testing but was not.

Agree with others that snap downgrade is not necessarily a= good choice here.=C2=A0 Either way, if I were in your shoes, I'd be lo= ading 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?=C2=A0 Version upgrades these days are usually pretty painless = except for some performance issues, unless you have some unusual situations= , for example, exotic extensions.=C2=A0

merlin



--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000a4f55406400480fb--