Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
От | Tom Lane |
---|---|
Тема | Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq |
Дата | |
Msg-id | 495420.1749488572@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
|
Список | 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
В списке pgsql-bugs по дате отправления: