Re: Sometimes the output to the stdout in Windows disappears
Alexander Law <exclusion@gmail.com>
From: Alexander Lakhin <exclusion@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Victor Spirin <v.spirin@postgrespro.ru>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-10-16T16:00:00Z
Lists: pgsql-hackers
Attachments
- catch-missing-stdout.patch (text/x-patch) patch
Hello hackers, 13.09.2020 21:37, Tom Lane wrote: > I happened to try googling for other similar reports, and I found > a very interesting recent thread here: > > https://github.com/nodejs/node/issues/33166 > > It might not have the same underlying cause, of course, but it sure > sounds familiar. If Node.js are really seeing the same effect, > that would point to an underlying Windows bug rather than anything > Postgres is doing wrong. > > It doesn't look like the Node.js crew got any closer to > understanding the issue than we have, unfortunately. They made > their problem mostly go away by reverting a seemingly-unrelated > patch. But I can't help thinking that it's a timing-related bug, > and that patch was just unlucky enough to change the timing of > their tests so that they saw the failure frequently. I've managed to make a simple reproducer. Please look at the patch attached. There are two things crucial for reproducing the bug: ioctlsocket(sock, FIONBIO, &ioctlsocket_ret); // from pgwin32_socket() and WSACleanup(); I still can't understand what affects the effect. With this reproducer I get: vcregress taptest src\test\modules\connect ... t/000_connect.pl .. # test # t/000_connect.pl .. 13346/100000 # Failed test at t/000_connect.pl line 24. t/000_connect.pl .. 16714/100000 # Failed test at t/000_connect.pl line 24. t/000_connect.pl .. 26216/100000 # Failed test at t/000_connect.pl line 24. t/000_connect.pl .. 30077/100000 # Failed test at t/000_connect.pl line 24. t/000_connect.pl .. 36505/100000 # Failed test at t/000_connect.pl line 24. t/000_connect.pl .. 43647/100000 # Failed test at t/000_connect.pl line 24. t/000_connect.pl .. 53070/100000 # Failed test at t/000_connect.pl line 24. t/000_connect.pl .. 54402/100000 # Failed test at t/000_connect.pl line 24. t/000_connect.pl .. 55685/100000 # Failed test at t/000_connect.pl line 24. t/000_connect.pl .. 83193/100000 # Failed test at t/000_connect.pl line 24. t/000_connect.pl .. 99992/100000 # Looks like you failed 10 tests of 100000. t/000_connect.pl .. Dubious, test returned 10 (wstat 2560, 0xa00) Failed 10/100000 subtests But in our test farm the pg_bench test (from the installcheck-world suite that we run with using msys) can fail roughly on each third run. Perhaps it depends on I/O load. It seems, that searching files/scanning disk in parallel increases the probability of the glitch. I see no solution for this on the postgres side for now, but this information about Windows quirks could be useful in case someone stumbled upon it too. Best regards, Alexander
Commits
-
In libpq for Windows, call WSAStartup once and WSACleanup not at all.
- cdc7ace161d3 9.6.20 landed
- 883226441d67 11.10 landed
- 6acc31a201d8 9.5.24 landed
- 6670e91078b3 10.15 landed
- d2074daebe16 13.1 landed
- 407580aabb83 12.5 landed
- 7d00a6b2de8a 14.0 landed
-
Update the Winsock API version requested by libpq.
- d5a9a661fcd2 14.0 landed