Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2025-06-09T17:02:52Z
Lists: pgsql-bugs
I wrote:
> For a real fix, the narrowest answer would be to not round down
> toSend if we are using an SSL connection.  I wonder though if
> the round-down behavior is of any use with GSSAPI either, or
> more generally if it's sensible for anything except a Unix-pipe
> connection.

Indeed, it looks like we'd better disable the round-down for GSSAPI
too, because pg_GSS_write has exactly this same API requirement that
caller has to pass at least as much data as last time.

Interestingly, we got a report of such a failure with GSSAPI
awhile ago, and "fixed" it in commit d053a879b.  Apparently
the test case we were looking at then did not trigger this
specific pattern involving pqFlush followed by pqPutMsgEnd,
because that commit did not do anything to prevent this
failure pattern.

I'm disinclined to revert what d053a879b did, but we'd better
remove or update this comment:

+     * Note: it may seem attractive to report partial write completion once
+     * we've successfully sent any encrypted packets.  However, that can cause
+     * problems for callers; notably, pqPutMsgEnd's heuristic to send only
+     * full 8K blocks interacts badly with such a hack.  We won't save much,
+     * typically, by letting callers discard data early, so don't risk it.

			regards, tom lane



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Don't reduce output request size on non-Unix-socket connections.

  2. Fix timing-dependent failure in GSSAPI data transmission.