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
>>
>

Reply via email to