Hello Nathan,
08.03.2024 01:00, Nathan Bossart wrote:
> On Sun, Dec 10, 2023 at 12:00:01PM +0300, Alexander Lakhin wrote:
>> So I would not say that it's a dominant failure for now, and given that
>> 04a09ee lives in master only, maybe we can save two commits (Revert +
>> Revert of revert) while moving to a more persistent solution.
> I just checked in on this one to see whether we needed to create an "open
> item" for v17. While I'm not seeing the failures anymore, the patch that
> Alexander claimed should fix it [0] doesn't appear to have been committed,
> either. Perhaps this was fixed by something else...
>
> [0] https://postgr.es/m/CA%2BhUKGL0bikWSC2XW-zUgFWNVEpD_gEWXndi2PE5tWqmApkpZQ%40mail.gmail.com
I have re-run the tests and found out that the issue was fixed by
d3c5f37dd. It changed the inner of the loop "while (PQisBusy(conn))",
formerly contained in pgfdw_get_result() as follows:
/* Data available in socket? */
if (wc & WL_SOCKET_READABLE)
{
if (!PQconsumeInput(conn))
pgfdw_report_error(ERROR, NULL, conn, false, query);
}
->
/* Consume whatever data is available from the socket */
if (PQconsumeInput(conn) == 0)
{
/* trouble; expect PQgetResult() to return NULL */
break;
}
That is, the unconditional "if PQconsumeInput() ..." eliminates the test
timeout.
Best regards,
Alexander