From: Tom Lane <tgl@sss.pgh.pa.us>
To: lars@greiz-reinsdorf.de
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18210: libpq: PQputCopyData sometimes fails in non-blocking
 mode over GSSAPI encrypted connection
In-reply-to: <18210-4c6d0b14627f2eb8@postgresql.org>
References: <18210-4c6d0b14627f2eb8@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Wed, 22 Nov 2023 12:21:25 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1675677.1700665886.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 22 Nov 2023 10:11:26 -0500
Message-ID: <1675678.1700665886@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1675678.1700665886%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The error "GSSAPI caller failed to retransmit all data needing to be
> retried" is raised here:
> https://github.com/postgres/postgres/blob/eeb0ebad79d9350305d9e111fbac76=
e20fa4b2fe/src/interfaces/libpq/fe-secure-gssapi.c#L110
> It happens only in non-blocking mode over GSSAPI encrypted connections. =
It
> isn't reliable and depends on the network timing. When sending a 7MB fil=
e in
> alternating pieces of 27KB and 180 Byte per PQputCopyData() there is a 5=
0%
> chance to get the failure over the local network. It doesn't happen if T=
LS
> is used instead.

Hmm.

> The issue is fixed if I change libpq at either pqPutMsgEnd() or at
> pg_GSS_write().

Both of those seem like pretty obviously wrong "fixes".  However,
I'm not quite sure I see the problem clearly enough to propose
a fix I'd believe in.

> Unfortunately so far I'm unable to provide a repro script. Maybe the abo=
ve
> information is enough to understand the problem.

A repro script would be really really helpful here.

			regards, tom lane