Jacob Champion <jacob.champion@enterprisedb.com> writes:
> On Sat, May 24, 2025 at 12:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> * The backend's secure_open_gssapi allowed received initialization packets
>> to be up to buffer-size long, whereas libpq will choke sending them
>> if they're more than buffer-size minus sizeof(uint32). This isn't
>> actually a bug, since the buffer management is handled in such a way
>> that it's safe, but it seems very inconsistent. I changed the limit
>> to subtract off sizeof(uint32) in all cases, which incidentally
>> allowed removing one variant of the translatable message string.
> That discrepancy is confusing to me. Is there a way to standardize
> both sides in the other direction, so that they actually handle tokens
> up to the "max size"?
I don't think so, because that would create exactly the cross-version
discrepancy we need to avoid. (That is, if sender thinks it can do
16384 when receiver's limit is 16384-4, kaboom.) The patch proposes
to allow slop in this during the auth phase when the packet size is
really being determined by the underlying GSSAPI library anyway.
But once we're past that and our own code is slicing up the data
stream into packets, I think the max packet size is indeed an
inalterable part of the protocol.
Could we address your confusion by improving the comment about the
packet-size #define to point out that it includes the header word?
regards, tom lane
