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
Subject: Re: BUG #18907: SSL error: bad length failure during transfer data in
 pipeline mode with libpq
In-reply-to: <474412.1749479193@sss.pgh.pa.us>
References: <18907-d41b9bcf6f29edda@postgresql.org>
 <1055821.1745949960@sss.pgh.pa.us>
 <CAOYmi+kPBjLcHqbY1PK2bnvVJ90dBbJAp0vBfrDNHTdmscxvbg@mail.gmail.com>
 <1ba0f64a-9f35-4fb4-83b0-6c11a1b88740@gmail.com>
 <474412.1749479193@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Mon, 09 Jun 2025 10:26:33 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <495419.1749488572.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 09 Jun 2025 13:02:52 -0400
Message-ID: <495420.1749488572@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/495420.1749488572%40sss.pgh.pa.us>
Precedence: bulk

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 on=
ce
+     * we've successfully sent any encrypted packets.  However, that can =
cause
+     * problems for callers; notably, pqPutMsgEnd's heuristic to send onl=
y
+     * full 8K blocks interacts badly with such a hack.  We won't save mu=
ch,
+     * typically, by letting callers discard data early, so don't risk it=
.

			regards, tom lane