Re: Raising the SCRAM iteration count

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Raising the SCRAM iteration count
Date: 2023-03-03 22:13:36
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 27 Feb 2023, at 08:06, Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> + conn->scram_sha_256_iterations = atoi(value);
> + }
> This should match on "scram_iterations", which is the name of the
> GUC.


> Would the long-term plan be to use multiple variables in conn if
> we ever get to <method>:<iterations> that would require more parsing?

I personally don't think we'll see more than 2 or at most 3 values so parsing
that format shouldn't be a problem, but it can always be revisited if/when we
get there.

> Perhaps there should be a test with \password to make sure that libpq
> gets the call when the GUC is updated by a SET command?

That would indeed be nice, but is there a way to do this without a complicated
pump TAP expression? I was unable to think of a way but I might be missing

Daniel Gustafsson

Attachment Content-Type Size
v6-0001-Make-SCRAM-iteration-count-configurable.patch application/octet-stream 14.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema 2023-03-03 23:57:15 Re: running logical replication as the subscription owner
Previous Message Tom Lane 2023-03-03 22:08:32 Re: Making empty Bitmapsets always be NULL