Re: GSSENC'ed connection stalls while reconnection attempts.

At Mon, 13 Jul 2020 11:08:09 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> > At Fri, 10 Jul 2020 12:01:10 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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