On Fri, Jun 23, 2023 at 11:27 AM Abhishek Dasgupta < abhishekdasgupta...@gmail.com> 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 postgres14 > > Could 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 <mich...@paquier.xyz> > 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 >> >