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