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 1v3Ve9-00HKaq-Df for pgsql-general@arkaria.postgresql.org; Tue, 30 Sep 2025 08:23:41 +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 1v3Ve7-007XSh-FD for pgsql-general@arkaria.postgresql.org; Tue, 30 Sep 2025 08:23:40 +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 1v3Ve7-007XPF-23 for pgsql-general@lists.postgresql.org; Tue, 30 Sep 2025 08:23:39 +0000 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v3Ve4-000etK-1K for pgsql-general@postgresql.org; Tue, 30 Sep 2025 08:23:38 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-57bc9775989so5290644e87.1 for ; Tue, 30 Sep 2025 01:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759220615; x=1759825415; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cK3fviWmyKmbGrKMYc3HR+wVzOd8nsntNtKsbhYvlnA=; b=RyDc569H5CLkuGm06t63De3a3CpHA3XCF7QbwRWZc1cuO8cBZIuIueGxSKooCrZv6t zYAURop078qOpcbI57jh3gKW37aRkeXDOILKBPdt8gnZuN67VVO6lg5qIWohe8ixuGA0 u41vV/CQHERnBLiJFlBz+ucTSE3iFxfJ3h8yM+XvDtasj4G+wi3w+CKEYHCMdiJ/wEKl DMbl8lvAAlHbgZy8Ep2ohy0U89L74zkL8DtPVgAT4EnRPFpfewqDBr46skvGf2Kc8hZ8 5hu7BA/xjNxGfHcittlJtHm/jx2SMBGD+fMSK5F2aDLXS+dESYw9efg4JsKZAlmvpiYV GkMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759220615; x=1759825415; h=cc: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=cK3fviWmyKmbGrKMYc3HR+wVzOd8nsntNtKsbhYvlnA=; b=KVnKoF4H8fuVnaqoJ+wp2X44JwVxdL5Mn3b0zNtDpH7dSM4rfcWo8DF8asuhd/LeZI aX74R39noZXIX4vnWxEAvF2TycqbtAOeuwtceoxaKXkG5FODWS+PtHgDWTF8yU8/uIJA NoTLvuc+zLV8tKIwa4eUlWFQw072sC73S4AQTR1VU6AM/FIfK9mMVBzbI7rwes4WnR7V MsmkyLPCOFqftR5ujJE1eV9tdr4WupEW6n1deurUr+rRJbxxwaVeAJ8dqs6qzEE+Dyif afzQm3dIOQWUcqH/gMkovFjj14vOgmZ9oNtsgVsWiW3aeWzEUEOueXsCHacSg2CpYKkC QEvA== X-Gm-Message-State: AOJu0Yw7UeE7q/NrzdypHyO1hogMMQNDpkAyjiSJ4CZVH52LGAV8LGKt 98jCpBsJWRrqnlBYRpJK/qWMnBjUYiJQzmpOgbL7MBz2SpwAJgp1bhu+HzD15sQFRu6rJO9ViML TE5FHHmeIHXYDkjhl8am02hsqXBb+Jrs= X-Gm-Gg: ASbGncsxB4X/geEW3E1yHI370cvTocQuG0Scb+APJAkshhnz0Zf2Rk6KGSFBqispSJy oPDk7wbh2zQa27s4oTh+2qCwb7HGHOKuPd/9HOavxxRl8AMVeMZOPLFpdb79eTjrBXcp+p/ob+r M0+qnl08aHBJjmdfR65TvbSPYUNQNj8R49lylx7MOkYJMn+gujJ26kUYhM92ysUPQTDJVgBiq+8 MMw2wtPA6uSuBejVFhvlQid2KtHuhmdyUiiJ0groOeZ7nk4MZ4OxVR4nznJ0F3dxw9or0wv X-Google-Smtp-Source: AGHT+IEpbg93iTUdry/Qd7RFsLjUuzvDRkRvpovCKBAkeJ/JpRo1bcgmg5jnaMBwbstfVsQEhdbz4gDuC5zmfETmbK8= X-Received: by 2002:a2e:be1f:0:b0:36b:5945:d3e8 with SMTP id 38308e7fff4ca-36f7f248fdfmr60560801fa.39.1759220615233; Tue, 30 Sep 2025 01:23:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ashish Mukherjee Date: Tue, 30 Sep 2025 13:53:23 +0530 X-Gm-Features: AS18NWDLQrLCxOQVkAhVwIyDLR9oPpxeLE197lkHNU1of_M9KqXfMnDvXyMrCT4 Message-ID: Subject: Re: Downgrade pgsql 17 to pgsql 12 question To: Merlin Moncure Cc: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="000000000000da45210640007733" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000da45210640007733 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=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. Thi= s >> 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 ha= ve > some unusual situations, for example, exotic extensions. > > merlin > > --000000000000da45210640007733 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you all for your inputs.

Well, Pe= rcona TDE was leading to the queries being very inefficient / slow after up= grading 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 f= ine as there was no incompatibility. I restored from the binary dump with t= he -j option, as our database is huge. I completely agree that downgrade is= not a good option but a pragmatic one under the circumstances.=C2=A0
=

Now the consideration is to use some other encryption o= ption for the database which will work fine on pgsql 17. Cybertec's tec= hnology is one route, the other is EDB. I am happy to hear experiences of f= olks here with 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 <mmoncure@gma= il.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 downgrad= e from pgsql 17 to pgsql 12. This is because we found in production certain= incompatibilities=C2=A0between both versions for our database. It should h= ave been caught in testing but was not.
Agree with others that snap downgrade is not necessarily a goo= d choice here.=C2=A0 Either way, if I were in your shoes, I'd be loadin= g a plain text dump, maybe with some light massaging to strip out some comp= atibility issues.

Can you let us know what the han= g up is?=C2=A0 Version upgrades these days are usually pretty painless exce= pt for some performance issues, unless you have some unusual situations, fo= r example, exotic extensions.=C2=A0

merlin

--000000000000da45210640007733--