Date: Thu, 3 Oct 2024 17:17:01 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
	Michael Paquier <michael@paquier.xyz>,
	Alexander Lakhin <exclusion@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Should rolpassword be toastable?
Message-ID: <Zv8X3YVzuPfh1Fht@nathan>
References: <2047353.1726784074@sss.pgh.pa.us>
 <0a9b7f96-aa2f-41eb-8e69-62f7990ebf74@postgresql.org>
 <Zuzh6Nq750L9BZn5@nathan>
 <Zu0G7s-k8iECVG7i@paquier.xyz>
 <0d8f3541-13f4-4194-8dca-bae881cf1a9a@postgresql.org>
 <Zu2eT2H8OT3OXauc@nathan>
 <2445149.1726849661@sss.pgh.pa.us>
 <Zu8r0oO0Vi0FxdpB@nathan>
 <Zv8MTMy87pRlRqD_@nathan>
 <465160.1727991546@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <465160.1727991546@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/Zv8X3YVzuPfh1Fht%40nathan>
Precedence: bulk

On Thu, Oct 03, 2024 at 05:39:06PM -0400, Tom Lane wrote:
> I agree with the idea that complaining about the password being too
> long is far more intelligible than that.  Another problem with
> leaving it as it stands in HEAD is that the effective limit is now
> platform-specific, if not indeed dependent on the phase of the moon
> (or at least, the other contents of the pg_authid row).  I fear it
> would be very easy to construct cases where a password is accepted
> on one machine but fails with "row is too big" on another.  A
> uniform limit seems much less fraught with surprises.

I don't mind proceeding with the patch if there is strong support for it.
I wavered only because it's hard to be confident that we are choosing the
right limit.  AFAICT 256 bytes ought to be sufficient to avoid "row is too
big" errors independent of BLCKSZ today, but maybe someone will add another
varlena column in the future that breaks it.  Or maybe we add a new
password hashing method that produces longer strings.  Or maybe someone is
doing something really out there like storing additional information in the
salt.  I don't have any reason to believe that any of these things are
happening or are likely to happen anytime soon, but they seem similar in
likelihood to someone building a custom driver that generates ginormous
hashes.  But I can also buy the argument that none of this is a strong
enough reason to avoid making the error message nicer...

-- 
nathan