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
