Kyotaro Horiguchi <horikyota....@gmail.com> writes:
> At Fri, 10 Jul 2020 12:01:10 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in
>> The attached patch makes this all act more like the way SSL is handled,
>> and for me it resolves the reconnection problem.
> It looks good to me.
OK, thanks.
>>> The reason that psql doesn't notice the error is pqPacketSend returns
>>> STATUS_OK when write error occurred. That behavior contradicts to the
>>> comment of the function. The function is used only while making
>>> connection so it's ok to error out immediately by write failure. I
>>> think other usage of pqFlush while making a connection should report
>>> write failure the same way.
>> I'm disinclined to mess with that, because (a) I don't think it's the
>> actual source of the problem, and (b) it would affect way more than
>> just GSS mode.
> If I did that in pqFlush your objection would be right, but
> pqPacketSend is defined as "RETURNS: STATUS_ERROR if the write fails"
> so not doing that is just wrong. (pqSendSome reported write failure in
> this case.) For other parts in authentication code, I don't think it
> doesn't affect badly because authentication should proceed without any
> read/write overlapping.
As the comment for pqSendSome says, we report a write failure immediately
only if we also cannot read. I don't really see a reason why the behavior
described there isn't fine during initial connection as well. If you feel
that the comment for pqPacketSend needs adjustment, we can do that.
In any case, I'm quite against changing pqPacketSend's behavior because
"it's only used during initial connection"; there is nothing about the
function that restricts it to that case.
Bottom line here is that I'm suspicious of changing the behavior of
the read/write code on the strength of a bug in the GSS state management
logic. If there's a reason to change the read/write code, we should be
able to demonstrate it without the GSS bug.
regards, tom lane
