Amit Kapila <amit.kapila16@gmail.com> writes:
> On Thu, Nov 28, 2019 at 8:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think the correct question to ask is "why not all cases"?
> As of now, it seems to me that this happens only on Windows. I am not
> sure why so? I will investigate this further and share my findings.
A couple of interesting things stand out from looking at the buildfarm
failures:
* On some of the machines, it seems like "chomp" is failing to get
rid of all the trailing whitespace in $pid:
ok 4 - acquired pid for SIGTERM
not ok 5 - database foobar1 is used
# Failed test 'database foobar1 is used'
# at t/051_dropdb_force.pl line 71.
# got: '212024'
# expected: '212024
'
How can that be? It somewhat-accidentally doesn't seem to be
causing any additional problems, but still we need this test
step to work (or else remove it, it's not really essential).
* On all the failing machines, it's very clear from the postmaster
log that the backend knows why it's being terminated:
2019-11-28 13:47:56.320 UTC [212024:4] 051_dropdb_force.pl FATAL: terminating connection due to administrator command
So the question seems to be why libpq isn't reporting that
message before it detects connection-closed.
This triggered a vague memory, and after a bit of archives-digging,
I found this thread from a few months back:
https://www.postgresql.org/message-id/flat/CA%2BhUKGJowQypXSKsjws9A%2BnEQDD0-mExHZqFXtJ09N209rCO5A%40mail.gmail.com#0629f079bc59ecdaa0d6ac9f8f2c18ac
in which it's alleged that Windows' TCP stack is flat-out
broken and will drop not-yet-delivered data when the server
closes the connection.
If that's true, it's pretty nasty. Windows is about the
last platform where I'd want us to have behavior like this,
because we *will* get bug reports about it from novices.
If there's no other workaround, I'm tempted to propose
#ifdef WIN32
pg_sleep(1 second);
#endif
or something close to that, before we close the socket.
Or we could revert the whole feature. I'm not sure it's
worth fighting portability wars for.
regards, tom lane
