On Fri, Jun 23, 2023 at 11:27 AM Abhishek Dasgupta <abhishekdasgupta005@xxxxxxxxx> wrote:
Hey Michael,Thanks for the reply.This error is specific to the Postgres JDBC driver, which relies on
its own application layer for FIPS and SCRAM because it speaks
directly the protocol and because it has no dependency to libpq.The thing is we are currently using the same password, which is less than 112 bits in length, for both versions 11 and 14 of Postgres. Although I am not a Postgres expert, I would like to understand the specific changes in the Postgres JDBC driver that are causing this error in postgres14Could you please clarify if the Postgres JDBC driver has been updated between Postgres 11 and 14? I am also interested in knowing how I can investigate the root cause within the Postgres JDBC driver itself.
Additionally, I would like to inquire if there are any alternative steps to resolve this issue without requiring a password change to a length greater than 14 characters.
Are there any specific failures you are seeing in the PostgreSQL backend
that you find confusing?The FIPS error is the main source of confusion for me. It seems that this error occurs specifically during the cluster setup, which subsequently leads to the failure of the DB setup.On Fri, Jun 23, 2023 at 3:56 AM Michael Paquier <michael@xxxxxxxxxxx> wrote:On Thu, Jun 22, 2023 at 07:16:21PM +0530, Abhishek Dasgupta wrote:
> I am puzzled as to why this error occurs only with PostgreSQL 14 and not
> with PostgreSQL 11.
This error is specific to the Postgres JDBC driver, which relies on
its own application layer for FIPS and SCRAM because it speaks
directly the protocol and because it has no dependency to libpq. Are
there any specific failures you are seeing in the PostgreSQL backend
that you find confusing?
--
Michael
