Re: pgsql: Add tests for '-f' option in dropdb utility.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Amit Kapila <akapila(at)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Add tests for '-f' option in dropdb utility.
Date: 2019-11-28 20:55:21
Message-ID: 31225.1574974521@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:
> On Thu, Nov 28, 2019 at 8:16 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tomas Vondra 2019-11-28 21:29:23 pgsql: Fix choose_best_statistics to check clauses individually
Previous Message Alvaro Herrera 2019-11-28 19:54:48 pgsql: Remove useless "return;" lines