Alexander Lakhin <exclusion@gmail.com> writes:
> 13.05.2024 23:17, Tom Lane wrote:
>> 3. We don't know exactly why hamerkop suddenly started seeing these
>> failures, but a plausible theory emerges after noting that its
>> reported time for the successful "make check" step dropped pretty
>> substantially right when this started. In the v13 branch, "make
>> check" was taking 2:18 or more in the several runs right before the
>> first isolationcheck failure, but 1:40 or less just after. So it
>> looks like the animal was moved onto faster hardware.
> Yes, and one thing I can't explain yet, is why REL_14_STABLE+ timings
> substantially differ from REL_13_STABLE-, say, for the check stage:
As I mentioned in our off-list discussion, I have a lingering feeling
that this v14 commit could be affecting the results somehow:
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master Release: REL_14_BR [d5a9a661f] 2020-10-18 12:56:43 -0400
Update the Winsock API version requested by libpq.
According to Microsoft's documentation, 2.2 has been the current
version since Windows 98 or so. Moreover, that's what the Postgres
backend has been requesting since 2004 (cf commit 4cdf51e64).
So there seems no reason for libpq to keep asking for 1.1.
I didn't believe at the time that that'd have any noticeable effect,
but maybe it somehow made Winsock play a bit nicer with the GSS
support?
regards, tom lane