At Mon, 13 Jul 2020 11:08:09 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in
> Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> > At Fri, 10 Jul 2020 12:01:10 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote intgl> >> 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.
I'm fine with 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.
That sounds fair enough.
> 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.
Agreed to separate the change from this issue. I also don't think
that change in behavior dramatically improve the situation since we
should have had a bunch of trouble when a write actually failed in the
normal case.
I'm going to post a patch to change the comment of pqPacketSend.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center