pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedSometimes the output to the stdout in Windows disappears
16+ messages / 4 participants
[nested] [flat]
Commits from this thread:
2020-10-18 d5a9a661fc Update the Winsock API version requested by libpq.
2020-10-17 7d00a6b2de d2074daebe 407580aabb cdc7ace161 6acc31a201 6670e91078 883226441d In libpq for Windows, call WSAStartup once and WSACleanup not at all.
* Sometimes the output to the stdout in Windows disappears
@ 2020-08-31 18:20 Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 16+ messages in thread
From: Victor Spirin @ 2020-08-31 18:20 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
Hi!
Sometimes the output to stdout on Windows on multicore machines does not
go through after connecting and disconnecting to the server using the
PQconnectdbParams and PQfinish functions. I tested on 6 cores.
First we appeared this in some pgbench tests. Then we found that this
happens on any console program using PQconnectdbParams and PQfinish.
I am attaching a patch and a script for testing.
--
Victor Spirin
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
Attachments:
stdout.patch (text/plain, 527B) download
diff --git a/src/port/snprintf.c b/src/port/snprintf.c
index 83a8103..17dc505 100644
--- a/src/port/snprintf.c
+++ b/src/port/snprintf.c
@@ -313,6 +313,14 @@ flushbuffer(PrintfTarget *target)
target->failed = true;
}
target->bufptr = target->bufstart;
+ /*
+ * Sometimes the output to stdout on Windows on multicore machines
+ * does not go through after connecting and disconnecting to the server
+ * using the PQconnectdbParams and PQfinish functions.
+ */
+#ifdef WIN32
+ fflush(target->stream);
+#endif
}
test_clusterdb.pl (text/plain, 412B) download
use IPC::Run;
my $clopts = '-p 5432 -e --dbname=postgres -U postgres';
my $stdout;
my $stderr;
my @cmd = ('clusterdb', split /\s+/, $clopts);
my $ch;
for (my $i =0; $i < 2*4096; $i++) {
$ch = IPC::Run::run(\@cmd, '>', \$stdout, '2>', \$stderr);
if(not defined $stdout) {
print($i.": not defined\n");
}
if($stdout eq '') {
print($i.": stdout is empty\n");
}
if ( ($i % 100) == 0){
print("$i\n");
}
}
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
@ 2020-08-31 18:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
0 siblings, 1 reply; 16+ messages in thread
From: Tom Lane @ 2020-08-31 18:31 UTC (permalink / raw)
To: Victor Spirin <v.spirin@postgrespro.ru>; +Cc: pgsql-hackers@lists.postgresql.org
Victor Spirin <v.spirin@postgrespro.ru> writes:
> Sometimes the output to stdout on Windows on multicore machines does not
> go through after connecting and disconnecting to the server using the
> PQconnectdbParams and PQfinish functions. I tested on 6 cores.
Hm, why is this not Microsoft's bug to solve?
I do wonder if this report is related to the intermittent ecpg failures
we see on Windows machines, such as [1]. The details vary, but it's
always a case of a .stdout file ending up empty when it should not be.
I'd supposed though that it must be something specific to ecpg, since
we never see anything like that anywhere but the ecpg tests. Even if
you posit that libpq is doing something that somehow compromises stdio,
that should affect psql-based tests too.
> I am attaching a patch and a script for testing.
> [ forced fflush in every snprintf call ]
My goodness, that's a large hammer you're swinging. What effects has this
kluge got on performance?
While I think you may be on to something, this seems like a truly horrid
way to "fix" it. We need to dig down further and understand what is
actually happening.
regards, tom lane
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory&dt=2020-08-13%2022%3A15%3A05
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-08-31 19:38 ` Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 16+ messages in thread
From: Victor Spirin @ 2020-08-31 19:38 UTC (permalink / raw)
To: pgsql-hackers@lists.postgresql.org
I only found that calling WSACleanup instead of PQfinish has the same
effect.
I don't see any big performance issues due to the extra fflush call in
this place. I will be glad to find a more elegant solution.
Victor Spirin
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
31.08.2020 21:31, Tom Lane пишет:
> Victor Spirin <v.spirin@postgrespro.ru> writes:
>> Sometimes the output to stdout on Windows on multicore machines does not
>> go through after connecting and disconnecting to the server using the
>> PQconnectdbParams and PQfinish functions. I tested on 6 cores.
> Hm, why is this not Microsoft's bug to solve?
>
> I do wonder if this report is related to the intermittent ecpg failures
> we see on Windows machines, such as [1]. The details vary, but it's
> always a case of a .stdout file ending up empty when it should not be.
> I'd supposed though that it must be something specific to ecpg, since
> we never see anything like that anywhere but the ecpg tests. Even if
> you posit that libpq is doing something that somehow compromises stdio,
> that should affect psql-based tests too.
>
>> I am attaching a patch and a script for testing.
>> [ forced fflush in every snprintf call ]
> My goodness, that's a large hammer you're swinging. What effects has this
> kluge got on performance?
>
> While I think you may be on to something, this seems like a truly horrid
> way to "fix" it. We need to dig down further and understand what is
> actually happening.
>
> regards, tom lane
>
> [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dory&dt=2020-08-13%2022%3A15%3A05
>
>
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
@ 2020-09-13 18:37 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
0 siblings, 1 reply; 16+ messages in thread
From: Tom Lane @ 2020-09-13 18:37 UTC (permalink / raw)
To: Victor Spirin <v.spirin@postgrespro.ru>; +Cc: pgsql-hackers@lists.postgresql.org
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.
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-10-16 16:00 ` Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 16+ messages in thread
From: Alexander Lakhin @ 2020-10-16 16:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Victor Spirin <v.spirin@postgrespro.ru>; +Cc: pgsql-hackers@lists.postgresql.org
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
Attachments:
catch-missing-stdout.patch (text/x-patch, 2.3K) download
diff --git a/src/test/modules/connect/connect.c b/src/test/modules/connect/connect.c
new file mode 100644
index 0000000000..c875b7647b
--- /dev/null
+++ b/src/test/modules/connect/connect.c
@@ -0,0 +1,26 @@
+#include <stdio.h>
+#include <winsock.h>
+
+int
+main(int argc, char *argv[])
+{
+ WSADATA wsaData;
+ SOCKET sock;
+ int port = 5432;
+ struct sockaddr_in ai_addr;
+ unsigned long ioctlsocket_ret = 1;
+
+ if (argc > 1) port = atoi(argv[1]);
+
+ ai_addr.sin_family = AF_INET;
+ ai_addr.sin_addr.s_addr = inet_addr("127.0.0.1");
+ ai_addr.sin_port = htons(port);
+
+ WSAStartup(MAKEWORD(1, 1), &wsaData);
+ sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
+ ioctlsocket(sock, FIONBIO, &ioctlsocket_ret);
+ connect(sock, (SOCKADDR *) & ai_addr, sizeof (ai_addr));
+ fprintf(stdout, "test\n");
+ WSACleanup();
+ return 0;
+}
diff --git a/src/test/modules/connect/t/000_connect.pl b/src/test/modules/connect/t/000_connect.pl
new file mode 100644
index 0000000000..bd23d1e419
--- /dev/null
+++ b/src/test/modules/connect/t/000_connect.pl
@@ -0,0 +1,25 @@
+use strict;
+use warnings;
+
+use PostgresNode;
+use TestLib;
+use Test::More;
+use Test::More tests => 100000;
+
+# start a server
+my $node = get_new_node('main');
+$node->init;
+$node->start;
+
+my $stdout;
+my $stderr;
+my @cmd = ('connect', $node->port);
+
+IPC::Run::run(\@cmd, '>', \$stdout, '2>', \$stderr);
+diag($stdout);
+diag($stderr);
+
+for (my $i =0; $i < 100000; $i++) {
+ IPC::Run::run(\@cmd, '>', \$stdout, '2>', \$stderr);
+ ok(defined $stdout && $stdout ne '');
+}
diff --git a/src/tools/msvc/Mkvcbuild.pm b/src/tools/msvc/Mkvcbuild.pm
index 20da7985c1..70959fbb24 100644
--- a/src/tools/msvc/Mkvcbuild.pm
+++ b/src/tools/msvc/Mkvcbuild.pm
@@ -43,6 +43,7 @@ my $contrib_extrasource = {
'seg' => [ 'contrib/seg/segscan.l', 'contrib/seg/segparse.y' ],
};
my @contrib_excludes = (
+ 'connect',
'bool_plperl', 'commit_ts',
'hstore_plperl', 'hstore_plpython',
'intagg', 'jsonb_plperl',
@@ -423,6 +424,10 @@ sub mkvcbuild
$zic->AddDirResourceFile('src/timezone');
$zic->AddReference($libpgcommon, $libpgport);
+ my $test_connect = $solution->AddProject('connect', 'exe', 'utils');
+ $test_connect->AddFile('src/test/modules/connect/connect.c');
+ $test_connect->AddLibrary('ws2_32.lib');
+
if (!$solution->{options}->{xml})
{
push @contrib_excludes, 'xml2';
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
@ 2020-10-16 16:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 08:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-17 13:54 ` Re: Sometimes the output to the stdout in Windows disappears Andrew Dunstan <andrew@dunslane.net>
0 siblings, 2 replies; 16+ messages in thread
From: Tom Lane @ 2020-10-16 16:18 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
Alexander Lakhin <exclusion@gmail.com> writes:
> 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();
Oh, very interesting.
Now that you have it somewhat in captivity, maybe you could determine
some things:
1. Is it only stdout that's affected? What of other stdio streams?
(Note that testing stderr might be tricky because it's probably
line-buffered.)
2. Does an fflush() just before, or just after, WSACleanup() fix it?
> 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.
Depending on your answers to the above, maybe some hack like this
would be acceptable:
free(conn);
#ifdef WIN32
+ fflush(NULL);
WSACleanup();
#endif
}
It's not very nice for a library to be doing global things like that,
but if the alternative is loss of output, maybe we should.
But wait a minute: I just looked at Microsoft's docs [1] and found
In a multithreaded environment, WSACleanup terminates Windows Sockets
operations for all threads.
This makes me (a) wonder if that explains the side-effects on stdio,
and (b) question why libpq is calling WSACleanup at all.
What if we arranged to call WSAStartup just once, during the first
libpq connection-open in a process, and then never did WSACleanup?
Surely the OS can cope with that, and it eliminates any risk that
WSACleanup breaks something.
regards, tom lane
[1] https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsacleanup
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-10-17 08:00 ` Alexander Lakhin <exclusion@gmail.com>
2020-10-17 15:50 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 16+ messages in thread
From: Alexander Lakhin @ 2020-10-17 08:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
16.10.2020 19:18, Tom Lane wrote:
> Oh, very interesting.
> Now that you have it somewhat in captivity, maybe you could determine
> some things:
>
> 1. Is it only stdout that's affected? What of other stdio streams?
> (Note that testing stderr might be tricky because it's probably
> line-buffered.)
stderr is affected too. Just replacing stdout with stderr in connect.c
and 000_connect.pl gives the same result.
Moreover, the following modification:
...
outfile = fopen("out", "w");
...
fprintf(stdout, "stdout test\n");
fprintf(stderr, "stderr test\n");
fprintf(outfile, "outfile test\n");
WSACleanup();
...
---
for (my $i =0; $i < 100000; $i++) {
unlink('out');
IPC::Run::run(\@cmd, '>', \$stdout, '2>', \$stderr);
open(my $fh, '<', 'out') or die $!;
my $fileout = <$fh>;
ok(defined $fileout && $fileout ne '');
close($fh);
}
detects similar failures too. (On a fail the out file exists but has
zero size.)
> 2. Does an fflush() just before, or just after, WSACleanup() fix it?
"fflush(NULL);" just before or after WSACleanup() fixes things.
I've managed to record in ProcMon the activity log for a failed run
(aside normal runs). Excerpts from the log are attached. As we can see,
the failed process doesn't even try to write into IPC-Run's temp file.
> Depending on your answers to the above, maybe some hack like this
> would be acceptable:
>
> free(conn);
>
> #ifdef WIN32
> + fflush(NULL);
> WSACleanup();
> #endif
> }
>
> It's not very nice for a library to be doing global things like that,
> but if the alternative is loss of output, maybe we should.
But now we see that the WSACleanup call is a global thing by itself.
> But wait a minute: I just looked at Microsoft's docs [1] and found
>
> In a multithreaded environment, WSACleanup terminates Windows Sockets
> operations for all threads.
>
> This makes me (a) wonder if that explains the side-effects on stdio,
> and (b) question why libpq is calling WSACleanup at all.
> What if we arranged to call WSAStartup just once, during the first
> libpq connection-open in a process, and then never did WSACleanup?
> Surely the OS can cope with that, and it eliminates any risk that
> WSACleanup breaks something.
What bothers me is:
There must be a call to *WSACleanup* for each successful call to
WSAStartup
<https://docs.microsoft.com/en-us/windows/desktop/api/winsock/nf-winsock-wsastartup;.
Only the final *WSACleanup* function call performs the actual
cleanup. The preceding calls simply decrement an internal reference
count in the WS2_32.DLL.
So third-party application developers should understand that when using
libpq they would have to call WSACleanup one more time to perform "the
actual cleanup". (And thus WSAStartup is kind of like a global thing too.)
But may be it's a way better than to have a confirmed risk of losing data.
Best regards,
Alexander
Attachments:
Logfile-OK.CSV (text/csv, 8.3K) download
"Time of Day","Process Name","PID","Operation","Path","Result","Detail"
"6:46:00.6867994 AM","connect.EXE","1964","RegQueryKey","HKLM","SUCCESS","Query: <Unknown: 7 >"
"6:46:00.6868045 AM","connect.EXE","1964","RegOpenKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock","REPARSE","Desired Access: Read"
"6:46:00.6868108 AM","connect.EXE","1964","RegOpenKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock","SUCCESS","Desired Access: Read"
"6:46:00.6868173 AM","connect.EXE","1964","RegQueryValue","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock\MinSockaddrLength","SUCCESS","Type: REG_DWORD, Length: 4, Data: 16"
"6:46:00.6868222 AM","connect.EXE","1964","RegQueryValue","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock\MaxSockaddrLength","SUCCESS","Type: REG_DWORD, Length: 4, Data: 16"
"6:46:00.6868270 AM","connect.EXE","1964","RegQueryValue","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock\UseDelayedAcceptance","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0"
"6:46:00.6868324 AM","connect.EXE","1964","RegCloseKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock","SUCCESS",""
"6:46:00.6871675 AM","connect.EXE","1964","RegCloseKey","HKLM\System\CurrentControlSet\Services\WinSock2\Parameters\Protocol_Catalog9","SUCCESS",""
"6:46:00.6872047 AM","connect.EXE","1964","RegCloseKey","HKLM\System\CurrentControlSet\Services\WinSock2\Parameters\NameSpace_Catalog5","SUCCESS",""
"6:46:00.6873043 AM","connect.EXE","1964","FASTIO_NETWORK_QUERY_OPEN","C:\Windows\System32\kernel.appcore.dll","FAST IO DISALLOWED",""
"6:46:00.6874633 AM","connect.EXE","1964","IRP_MJ_CREATE","C:\Windows\System32\kernel.appcore.dll","SUCCESS","Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"
"6:46:00.6874866 AM","connect.EXE","1964","FASTIO_QUERY_INFORMATION","C:\Windows\System32\kernel.appcore.dll","SUCCESS","Type: QueryBasicInformationFile, CreationTime: 11/21/2014 7:47:53 AM, LastAccessTime: 11/21/2014 7:47:53 AM, LastWriteTime: 11/21/2014 7:47:53 AM, ChangeTime: 12/4/2019 2:31:34 PM, FileAttributes: A"
"6:46:00.6874966 AM","connect.EXE","1964","IRP_MJ_CLEANUP","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:00.6875074 AM","connect.EXE","1964","IRP_MJ_CLOSE","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:00.6875782 AM","connect.EXE","1964","IRP_MJ_CREATE","C:\Windows\System32\kernel.appcore.dll","SUCCESS","Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened"
"6:46:00.6875970 AM","connect.EXE","1964","FASTIO_ACQUIRE_FOR_SECTION_SYNCHRONIZATION","C:\Windows\System32\kernel.appcore.dll","FILE LOCKED WITH ONLY READERS","SyncType: SyncTypeCreateSection, PageProtection: "
"6:46:00.6876058 AM","connect.EXE","1964","FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:00.6876143 AM","connect.EXE","1964","FASTIO_ACQUIRE_FOR_SECTION_SYNCHRONIZATION","C:\Windows\System32\kernel.appcore.dll","SUCCESS","SyncType: SyncTypeOther"
"6:46:00.6876789 AM","connect.EXE","1964","FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:00.6878993 AM","connect.EXE","1964","IRP_MJ_CLEANUP","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:00.6879153 AM","connect.EXE","1964","IRP_MJ_CLOSE","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:00.6884862 AM","connect.EXE","1964","RegOpenKey","HKLM\SYSTEM\CurrentControlSet\Control\Session Manager","REPARSE","Desired Access: Query Value, Enumerate Sub Keys"
"6:46:00.6885024 AM","connect.EXE","1964","RegOpenKey","HKLM\System\CurrentControlSet\Control\Session Manager","SUCCESS","Desired Access: Query Value, Enumerate Sub Keys"
"6:46:00.6885109 AM","connect.EXE","1964","RegQueryValue","HKLM\System\CurrentControlSet\Control\SESSION MANAGER\ResourcePolicies","NAME NOT FOUND","Length: 24"
"6:46:00.6885183 AM","connect.EXE","1964","RegCloseKey","HKLM\System\CurrentControlSet\Control\SESSION MANAGER","SUCCESS",""
"6:46:00.6885954 AM","connect.EXE","1964","IRP_MJ_WRITE","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053864","SUCCESS","Offset: 0, Length: 13, Priority: Normal"
"6:46:00.6886284 AM","connect.EXE","1964","IRP_MJ_WRITE","C:\$LogFile","SUCCESS","Offset: 114,688, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
"6:46:00.6888096 AM","connect.EXE","1964","IRP_MJ_WRITE","C:\$LogFile","SUCCESS","Offset: 49,152, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
"6:46:00.6889418 AM","connect.EXE","1964","FASTIO_ACQUIRE_FOR_CC_FLUSH","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053864","SUCCESS",""
"6:46:00.6889563 AM","connect.EXE","1964","IRP_MJ_WRITE","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053864","SUCCESS","Offset: 0, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
"6:46:00.6950728 AM","connect.EXE","1964","FASTIO_ACQUIRE_FOR_CC_FLUSH","C:\$Mft","SUCCESS",""
"6:46:00.6950952 AM","connect.EXE","1964","IRP_MJ_WRITE","C:\$Mft","SUCCESS","Offset: 217,112,576, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
"6:46:00.6952326 AM","connect.EXE","1964","FASTIO_RELEASE_FOR_CC_FLUSH","C:\$Mft","SUCCESS",""
"6:46:00.6952494 AM","connect.EXE","1964","FASTIO_RELEASE_FOR_CC_FLUSH","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053864","SUCCESS",""
"6:46:00.6952847 AM","connect.EXE","1964","IRP_MJ_WRITE","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053865","SUCCESS","Offset: 0, Length: 13, Priority: Normal"
"6:46:00.6953435 AM","connect.EXE","1964","IRP_MJ_WRITE","C:\$LogFile","SUCCESS","Offset: 114,688, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
"6:46:00.6955444 AM","connect.EXE","1964","IRP_MJ_WRITE","C:\$LogFile","SUCCESS","Offset: 53,248, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
"6:46:00.6957051 AM","connect.EXE","1964","FASTIO_ACQUIRE_FOR_CC_FLUSH","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053865","SUCCESS",""
"6:46:00.6957250 AM","connect.EXE","1964","IRP_MJ_WRITE","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053865","SUCCESS","Offset: 0, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
"6:46:00.7065464 AM","connect.EXE","1964","FASTIO_ACQUIRE_FOR_CC_FLUSH","C:\$Mft","SUCCESS",""
"6:46:00.7065652 AM","connect.EXE","1964","IRP_MJ_WRITE","C:\$Mft","SUCCESS","Offset: 220,413,952, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
"6:46:00.7067828 AM","connect.EXE","1964","FASTIO_RELEASE_FOR_CC_FLUSH","C:\$Mft","SUCCESS",""
"6:46:00.7067993 AM","connect.EXE","1964","FASTIO_RELEASE_FOR_CC_FLUSH","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053865","SUCCESS",""
"6:46:00.7070538 AM","connect.EXE","1964","IRP_MJ_CLEANUP","C:\src\postgresql\src\test\modules\connect","SUCCESS",""
"6:46:00.7070627 AM","connect.EXE","1964","IRP_MJ_CLOSE","C:\src\postgresql\src\test\modules\connect","SUCCESS",""
"6:46:00.7070846 AM","connect.EXE","1964","RegCloseKey","HKLM\System\CurrentControlSet\Control\SESSION MANAGER","SUCCESS",""
"6:46:00.7071136 AM","connect.EXE","1964","RegCloseKey","HKLM\System\CurrentControlSet\Control\Nls\Sorting\Versions","SUCCESS",""
"6:46:00.7071181 AM","connect.EXE","1964","RegCloseKey","HKLM","SUCCESS",""
"6:46:00.7195845 AM","perl.exe","2756","FASTIO_READ","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053864","SUCCESS","Offset: 0, Length: 13"
"6:46:00.7196977 AM","perl.exe","2756","FASTIO_READ","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053864","END OF FILE","Offset: 13, Length: 999,999"
"6:46:00.7197375 AM","perl.exe","2756","IRP_MJ_DEVICE_CONTROL","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053864","FAST IO DISALLOWED","Control: 0x12043 (Device:0x1 Function:2064 Method: 3)"
Logfile-FAIL.CSV (text/csv, 5.3K) download
"Time of Day","Process Name","PID","Operation","Path","Result","Detail"
"6:46:01.7192801 AM","connect.EXE","912","RegQueryKey","HKLM","SUCCESS","Query: <Unknown: 7 >"
"6:46:01.7192850 AM","connect.EXE","912","RegOpenKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock","REPARSE","Desired Access: Read"
"6:46:01.7192907 AM","connect.EXE","912","RegOpenKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock","SUCCESS","Desired Access: Read"
"6:46:01.7192966 AM","connect.EXE","912","RegQueryValue","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock\MinSockaddrLength","SUCCESS","Type: REG_DWORD, Length: 4, Data: 16"
"6:46:01.7193012 AM","connect.EXE","912","RegQueryValue","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock\MaxSockaddrLength","SUCCESS","Type: REG_DWORD, Length: 4, Data: 16"
"6:46:01.7193054 AM","connect.EXE","912","RegQueryValue","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock\UseDelayedAcceptance","SUCCESS","Type: REG_DWORD, Length: 4, Data: 0"
"6:46:01.7193106 AM","connect.EXE","912","RegCloseKey","HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Winsock","SUCCESS",""
"6:46:01.7201104 AM","connect.EXE","912","RegCloseKey","HKLM\System\CurrentControlSet\Services\WinSock2\Parameters\Protocol_Catalog9","SUCCESS",""
"6:46:01.7201252 AM","connect.EXE","912","RegCloseKey","HKLM\System\CurrentControlSet\Services\WinSock2\Parameters\NameSpace_Catalog5","SUCCESS",""
"6:46:01.7202319 AM","connect.EXE","912","FASTIO_NETWORK_QUERY_OPEN","C:\Windows\System32\kernel.appcore.dll","FAST IO DISALLOWED",""
"6:46:01.7203969 AM","connect.EXE","912","IRP_MJ_CREATE","C:\Windows\System32\kernel.appcore.dll","SUCCESS","Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"
"6:46:01.7204185 AM","connect.EXE","912","FASTIO_QUERY_INFORMATION","C:\Windows\System32\kernel.appcore.dll","SUCCESS","Type: QueryBasicInformationFile, CreationTime: 11/21/2014 7:47:53 AM, LastAccessTime: 11/21/2014 7:47:53 AM, LastWriteTime: 11/21/2014 7:47:53 AM, ChangeTime: 12/4/2019 2:31:34 PM, FileAttributes: A"
"6:46:01.7204290 AM","connect.EXE","912","IRP_MJ_CLEANUP","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:01.7204435 AM","connect.EXE","912","IRP_MJ_CLOSE","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:01.7205422 AM","connect.EXE","912","IRP_MJ_CREATE","C:\Windows\System32\kernel.appcore.dll","SUCCESS","Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened"
"6:46:01.7205920 AM","connect.EXE","912","FASTIO_ACQUIRE_FOR_SECTION_SYNCHRONIZATION","C:\Windows\System32\kernel.appcore.dll","FILE LOCKED WITH ONLY READERS","SyncType: SyncTypeCreateSection, PageProtection: "
"6:46:01.7206011 AM","connect.EXE","912","FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:01.7206088 AM","connect.EXE","912","FASTIO_ACQUIRE_FOR_SECTION_SYNCHRONIZATION","C:\Windows\System32\kernel.appcore.dll","SUCCESS","SyncType: SyncTypeOther"
"6:46:01.7206139 AM","connect.EXE","912","FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:01.7208406 AM","connect.EXE","912","IRP_MJ_READ","C:\Windows\System32\mswsock.dll","SUCCESS","Offset: 78,848, Length: 32,768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal"
"6:46:01.7208457 AM","connect.EXE","912","IRP_MJ_CLEANUP","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:01.7208579 AM","connect.EXE","912","IRP_MJ_CLOSE","C:\Windows\System32\kernel.appcore.dll","SUCCESS",""
"6:46:01.7215400 AM","connect.EXE","912","RegOpenKey","HKLM\SYSTEM\CurrentControlSet\Control\Session Manager","REPARSE","Desired Access: Query Value, Enumerate Sub Keys"
"6:46:01.7215594 AM","connect.EXE","912","RegOpenKey","HKLM\System\CurrentControlSet\Control\Session Manager","SUCCESS","Desired Access: Query Value, Enumerate Sub Keys"
"6:46:01.7215765 AM","connect.EXE","912","RegQueryValue","HKLM\System\CurrentControlSet\Control\SESSION MANAGER\ResourcePolicies","NAME NOT FOUND","Length: 24"
"6:46:01.7215895 AM","connect.EXE","912","RegCloseKey","HKLM\System\CurrentControlSet\Control\SESSION MANAGER","SUCCESS",""
"6:46:01.7224784 AM","connect.EXE","912","IRP_MJ_CLEANUP","C:\src\postgresql\src\test\modules\connect","SUCCESS",""
"6:46:01.7224892 AM","connect.EXE","912","IRP_MJ_CLOSE","C:\src\postgresql\src\test\modules\connect","SUCCESS",""
"6:46:01.7225069 AM","connect.EXE","912","RegCloseKey","HKLM\System\CurrentControlSet\Control\SESSION MANAGER","SUCCESS",""
"6:46:01.7225785 AM","connect.EXE","912","RegCloseKey","HKLM\System\CurrentControlSet\Control\Nls\Sorting\Versions","SUCCESS",""
"6:46:01.7225825 AM","connect.EXE","912","RegCloseKey","HKLM","SUCCESS",""
"6:46:01.7496773 AM","perl.exe","2756","IRP_MJ_READ","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053866","END OF FILE","Offset: 0, Length: 999,999, Priority: Normal"
"6:46:01.7497439 AM","perl.exe","2756","IRP_MJ_DEVICE_CONTROL","C:\Users\Administrator\AppData\Local\Temp\IPC-Run.tmp\Win32io-002756-00053866","FAST IO DISALLOWED","Control: 0x12043 (Device:0x1 Function:2064 Method: 3)"
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 08:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
@ 2020-10-17 15:50 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 18:44 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 16+ messages in thread
From: Tom Lane @ 2020-10-17 15:50 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
Alexander Lakhin <exclusion@gmail.com> writes:
> 16.10.2020 19:18, Tom Lane wrote:
>> What if we arranged to call WSAStartup just once, during the first
>> libpq connection-open in a process, and then never did WSACleanup?
>> Surely the OS can cope with that, and it eliminates any risk that
>> WSACleanup breaks something.
> What bothers me is:
> There must be a call to *WSACleanup* for each successful call to
> WSAStartup
> <https://docs.microsoft.com/en-us/windows/desktop/api/winsock/nf-winsock-wsastartup;.
Yeah, that is a very odd statement. Surely, the Windows kernel manages
to cope if a program crashes without having done that. So what exactly
is the downside of intentionally not doing it? There's no reason to
care if the Winsock DLL stays loaded until program exit rather than
getting unloaded a bit earlier. (If anything, the current code causes
an unload/reload cycle for each connection when the application makes
a series of PG connections; who could think that's a great idea?)
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 08:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-17 15:50 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-10-17 18:44 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
0 siblings, 1 reply; 16+ messages in thread
From: Tom Lane @ 2020-10-17 18:44 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
I wrote:
> Alexander Lakhin <exclusion@gmail.com> writes:
>> What bothers me is:
>> There must be a call to *WSACleanup* for each successful call to
>> WSAStartup
>> <https://docs.microsoft.com/en-us/windows/desktop/api/winsock/nf-winsock-wsastartup;.
> Yeah, that is a very odd statement. Surely, the Windows kernel manages
> to cope if a program crashes without having done that. So what exactly
> is the downside of intentionally not doing it?
A bit of grepping showed me that the backend, initdb, and pg_regress
all call WSAStartup without ever doing WSACleanup, and we've seen no
ill effects from that. So it seems clear that this documentation can
safely be ignored.
I propose the attached patch. If this doesn't cause buildfarm problems,
perhaps we should back-patch it.
BTW, I notice that libpq is asking WSAStartup for Winsock version 1.1,
which is remarkably ancient. Almost everyplace else is asking for
version 2.2, which has been current for a decade or two. Shouldn't
we update that? (It occurs to me to wonder if this in itself is
some kind of problem; I wonder how well Winsock works when there are
requests for different API versions in the same program.)
regards, tom lane
Attachments:
remove-WSACleanup-calls.patch (text/x-diff, 3.5K) download
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 3315f1dd05..de60281fcb 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -91,21 +91,6 @@
</para>
</warning>
- <note>
- <para>
- On Windows, there is a way to improve performance if a single
- database connection is repeatedly started and shutdown. Internally,
- libpq calls <function>WSAStartup()</function> and <function>WSACleanup()</function> for connection startup
- and shutdown, respectively. <function>WSAStartup()</function> increments an internal
- Windows library reference count which is decremented by <function>WSACleanup()</function>.
- When the reference count is just one, calling <function>WSACleanup()</function> frees
- all resources and all DLLs are unloaded. This is an expensive
- operation. To avoid this, an application can manually call
- <function>WSAStartup()</function> so resources will not be freed when the last database
- connection is closed.
- </para>
- </note>
-
<variablelist>
<varlistentry id="libpq-PQconnectdbParams">
<term><function>PQconnectdbParams</function><indexterm><primary>PQconnectdbParams</primary></indexterm></term>
diff --git a/src/bin/pg_dump/parallel.c b/src/bin/pg_dump/parallel.c
index a967e11378..b51cc76c7d 100644
--- a/src/bin/pg_dump/parallel.c
+++ b/src/bin/pg_dump/parallel.c
@@ -229,19 +229,6 @@ static char *readMessageFromPipe(int fd);
(strncmp(msg, prefix, strlen(prefix)) == 0)
-/*
- * Shutdown callback to clean up socket access
- */
-#ifdef WIN32
-static void
-shutdown_parallel_dump_utils(int code, void *unused)
-{
- /* Call the cleanup function only from the main thread */
- if (mainThreadId == GetCurrentThreadId())
- WSACleanup();
-}
-#endif
-
/*
* Initialize parallel dump support --- should be called early in process
* startup. (Currently, this is called whether or not we intend parallel
@@ -267,8 +254,7 @@ init_parallel_dump_utils(void)
pg_log_error("WSAStartup failed: %d", err);
exit_nicely(1);
}
- /* ... and arrange to shut it down at exit */
- on_exit_nicely(shutdown_parallel_dump_utils, NULL);
+
parallel_init_done = true;
}
#endif
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index af27fee6b5..704c9e2f79 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -3871,23 +3871,30 @@ makeEmptyPGconn(void)
#ifdef WIN32
/*
- * Make sure socket support is up and running.
+ * Make sure socket support is up and running in this process.
+ *
+ * Note: the Windows documentation says that we should eventually do a
+ * matching WSACleanup() call, but experience suggests that that is at
+ * least as likely to cause problems as fix them. So we don't.
*/
- WSADATA wsaData;
+ static bool wsastartup_done = false;
- if (WSAStartup(MAKEWORD(1, 1), &wsaData))
- return NULL;
+ if (!wsastartup_done)
+ {
+ WSADATA wsaData;
+
+ if (WSAStartup(MAKEWORD(1, 1), &wsaData) != 0)
+ return NULL;
+ wsastartup_done = true;
+ }
+
+ /* Forget any earlier error */
WSASetLastError(0);
-#endif
+#endif /* WIN32 */
conn = (PGconn *) malloc(sizeof(PGconn));
if (conn == NULL)
- {
-#ifdef WIN32
- WSACleanup();
-#endif
return conn;
- }
/* Zero all pointers and booleans */
MemSet(conn, 0, sizeof(PGconn));
@@ -4080,10 +4087,6 @@ freePGconn(PGconn *conn)
termPQExpBuffer(&conn->workBuffer);
free(conn);
-
-#ifdef WIN32
- WSACleanup();
-#endif
}
/*
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 08:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-17 15:50 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 18:44 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-10-18 18:00 ` Alexander Lakhin <exclusion@gmail.com>
2020-10-18 18:04 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:33 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 16+ messages in thread
From: Alexander Lakhin @ 2020-10-18 18:00 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
17.10.2020 21:44, Tom Lane wrote:
> I propose the attached patch. If this doesn't cause buildfarm problems,
> perhaps we should back-patch it.
Thank you!
I've made a simple cmd script to reproduce problems seen on dory:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=dory&br=HEAD
FOR /L %%I IN (1,1,200) DO call :CHECK %%I
GOTO :eof
:CHECK
echo iteration %1
call vcregress ecpgcheck
IF %ERRORLEVEL% NEQ 0 GOTO ERR
EXIT /B
:ERR
echo iteration %1 failed
pause
Without the fix I've got errors on iterations 43, 46, 128, 47, 14, 4,
27, which approximately corresponds to the ECPG-Check failure frequency
on dory (for HEAD).
With the fix all the 200 iterations passed as expected.
Then I ran the loop again just to be sure and got:
test thread/descriptor ... stderr FAILED 81 ms
iteration 124 failed.
diff -w -U3
.../src/interfaces/ecpg/test/expected/thread-descriptor.stderr
.../src/interfaces/ecpg/test/results/thread-descriptor.stderr
--- .../src/interfaces/ecpg/test/expected/thread-descriptor.stderr
2019-12-04 16:05:46 +0300
+++ .../src/interfaces/ecpg/test/results/thread-descriptor.stderr
2020-10-18 20:20:27 +0300
@@ -0,0 +1 @@
+SQL error: descriptor "mydesc" not found on line 31
It's interesting that all failures before the fix were with stdout, but
this one is with stderr.
I'm going to investigate this issue further.
Best regards,
Alexander
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 08:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-17 15:50 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 18:44 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
@ 2020-10-18 18:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:24 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:30 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
1 sibling, 2 replies; 16+ messages in thread
From: Tom Lane @ 2020-10-18 18:04 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
Alexander Lakhin <exclusion@gmail.com> writes:
> With the fix all the 200 iterations passed as expected.
> Then I ran the loop again just to be sure and got:
> test thread/descriptor ... stderr FAILED 81 ms
> iteration 124 failed.
Sigh ... still, this:
> diff -w -U3
> .../src/interfaces/ecpg/test/expected/thread-descriptor.stderr
> .../src/interfaces/ecpg/test/results/thread-descriptor.stderr
> --- .../src/interfaces/ecpg/test/expected/thread-descriptor.stderr
> 2019-12-04 16:05:46 +0300
> +++ .../src/interfaces/ecpg/test/results/thread-descriptor.stderr
> 2020-10-18 20:20:27 +0300
> @@ -0,0 +1 @@
> +SQL error: descriptor "mydesc" not found on line 31
does not look like the same kind of failure as what we've been dealing
with up to now. So maybe what we've got is that we fixed the stdio
loss problem, and now the error rate is down to the point where we can
notice other, even-lower-probability issues.
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 08:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-17 15:50 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 18:44 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-18 18:04 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-10-18 18:24 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 16+ messages in thread
From: Tom Lane @ 2020-10-18 18:24 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
I wrote:
>> diff -w -U3
>> .../src/interfaces/ecpg/test/expected/thread-descriptor.stderr
>> .../src/interfaces/ecpg/test/results/thread-descriptor.stderr
>> --- .../src/interfaces/ecpg/test/expected/thread-descriptor.stderr
>> 2019-12-04 16:05:46 +0300
>> +++ .../src/interfaces/ecpg/test/results/thread-descriptor.stderr
>> 2020-10-18 20:20:27 +0300
>> @@ -0,0 +1 @@
>> +SQL error: descriptor "mydesc" not found on line 31
> does not look like the same kind of failure as what we've been dealing
> with up to now. So maybe what we've got is that we fixed the stdio
> loss problem, and now the error rate is down to the point where we can
> notice other, even-lower-probability issues.
Yeah, I think so. I grepped the buildfarm logs for similar failures and
found three occurrences:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-02-03%2018%3A36%3A05
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-01-17%2014%3A30%3A07
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2020-01-02%2018%3A03%3A52
All of these are in the thread/descriptor test, failing at the deallocate
step in
for (i = 1; i <= REPEATS; ++i)
{
EXEC SQL ALLOCATE DESCRIPTOR mydesc;
EXEC SQL DEALLOCATE DESCRIPTOR mydesc;
}
where the test is running several of these in different threads.
I wonder whether there's some missing thread-locking in the ECPG
descriptor support. It is odd though that we have seen this only
on Windows members. Low-probability or not, you'd think we'd have
some similar reports from non-Windows critters if it were possible.
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 08:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-17 15:50 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 18:44 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-18 18:04 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-10-18 18:30 ` Alexander Lakhin <exclusion@gmail.com>
2020-10-18 18:38 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 16+ messages in thread
From: Alexander Lakhin @ 2020-10-18 18:30 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
18.10.2020 21:04, Tom Lane wrote:
> Alexander Lakhin <exclusion@gmail.com> writes:
>> @@ -0,0 +1 @@
>> +SQL error: descriptor "mydesc" not found on line 31
> does not look like the same kind of failure as what we've been dealing
> with up to now. So maybe what we've got is that we fixed the stdio
> loss problem, and now the error rate is down to the point where we can
> notice other, even-lower-probability issues.
Yes, in this case stderr is not missing (it's present with the error).
So it's really different case. As is another one:
test connect/test5 ... stderr FAILED 238 ms
diff -w -U3 .../src/interfaces/ecpg/test/expected/connect-test5.stderr
.../src/interfaces/ecpg/test/results/connect-test5.stderr
--- .../src/interfaces/ecpg/test/expected/connect-test5.stderr
2020-10-13 21:51:14 +0300
+++ .../src/interfaces/ecpg/test/results/connect-test5.stderr
2020-10-18 20:59:46 +0300
@@ -73,7 +73,9 @@
[NO_PID]: sqlca: code: -220, state: 08003
[NO_PID]: ECPGconnect: opening database <DEFAULT> on <DEFAULT> port
<DEFAULT> for user regress_ecpg_user2
[NO_PID]: sqlca: code: 0, state: 00000
-[NO_PID]: ECPGconnect: could not open database: FATAL: database
"regress_ecpg_user2" does not exist
+[NO_PID]: ECPGconnect: could not open database: server closed the
connection unexpectedly
+ This probably means the server terminated abnormally
+ before or while processing the request.
and the server.log:
2020-10-18 20:59:45.731 MSK client backend[1380] ecpg/connect-test4
LOG: could not receive data from client: An existing connection was
forcibly closed by the remote host.
2020-10-18 20:59:45.898 MSK client backend[2884] [unknown] FATAL:
database "regress_ecpg_user2" does not exist
2020-10-18 20:59:45.992 MSK client backend[1640] [unknown] FATAL:
database "regress_ecpg_user2" does not exist
I just wanted to inform that the ECPG-test failures can still persist in
the buildfarm, unfortunately.
Best regards,
Alexander
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 08:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-17 15:50 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 18:44 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-18 18:04 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:30 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
@ 2020-10-18 18:38 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 16+ messages in thread
From: Tom Lane @ 2020-10-18 18:38 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
Alexander Lakhin <exclusion@gmail.com> writes:
> I just wanted to inform that the ECPG-test failures can still persist in
> the buildfarm, unfortunately.
Right, but at least now we can see that there are other issues to
investigate. Personally I stopped paying any attention to buildfarm
ECPG failures on Windows some time ago, figuring they were all the
mysterious stdout-truncation problem. With that gone there'll be
less noise and more signal in the buildfarm results.
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 08:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-17 15:50 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 18:44 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
@ 2020-10-18 18:33 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 16+ messages in thread
From: Tom Lane @ 2020-10-18 18:33 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
Alexander Lakhin <exclusion@gmail.com> writes:
> I've made a simple cmd script to reproduce problems seen on dory:
> ...
> Without the fix I've got errors on iterations 43, 46, 128, 47, 14, 4,
> 27, which approximately corresponds to the ECPG-Check failure frequency
> on dory (for HEAD).
> With the fix all the 200 iterations passed as expected.
> Then I ran the loop again just to be sure and got:
> test thread/descriptor ... stderr FAILED 81 ms
> iteration 124 failed.
I had been thinking we'd have to wait a month or two for the buildfarm
to accumulate enough runs to be confident in whether the WSACleanup
removal fixes the ecpg failures. However, now that you did this
experiment, I think we have enough evidence already that it fixes it
(or at least makes things an order of magnitude better).
So now I'm inclined to not wait, but go ahead and backpatch 7d00a6b2d
now. There's still enough time before the November releases that we
can expect that any nasty problems will show up in the buildfarm
before we ship.
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: Sometimes the output to the stdout in Windows disappears
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Re: Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Re: Sometimes the output to the stdout in Windows disappears Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Re: Sometimes the output to the stdout in Windows disappears Tom Lane <tgl@sss.pgh.pa.us>
@ 2020-10-17 13:54 ` Andrew Dunstan <andrew@dunslane.net>
1 sibling, 0 replies; 16+ messages in thread
From: Andrew Dunstan @ 2020-10-17 13:54 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Alexander Lakhin <exclusion@gmail.com>; +Cc: Victor Spirin <v.spirin@postgrespro.ru>; pgsql-hackers@lists.postgresql.org
On 10/16/20 12:18 PM, Tom Lane wrote:
>
> But wait a minute: I just looked at Microsoft's docs [1] and found
>
> In a multithreaded environment, WSACleanup terminates Windows Sockets
> operations for all threads.
>
> This makes me (a) wonder if that explains the side-effects on stdio,
> and (b) question why libpq is calling WSACleanup at all.
> What if we arranged to call WSAStartup just once, during the first
> libpq connection-open in a process, and then never did WSACleanup?
> Surely the OS can cope with that, and it eliminates any risk that
> WSACleanup breaks something.
>
> regards, tom lane
>
> [1] https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsacleanup
>
>
This could explain random transient stdout/stderr failures we have seen
over the years. I think we should at least give your suggestion a try -
this is a good time in the dev cycle for such experiments.
cheers
andrew
^ permalink raw reply [nested|flat] 16+ messages in thread
end of thread, other threads:[~2020-10-18 18:38 UTC | newest]
Thread overview: 16+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-08-31 18:20 Sometimes the output to the stdout in Windows disappears Victor Spirin <v.spirin@postgrespro.ru>
2020-08-31 18:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-08-31 19:38 ` Victor Spirin <v.spirin@postgrespro.ru>
2020-09-13 18:37 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-16 16:00 ` Alexander Lakhin <exclusion@gmail.com>
2020-10-16 16:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 08:00 ` Alexander Lakhin <exclusion@gmail.com>
2020-10-17 15:50 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 18:44 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:00 ` Alexander Lakhin <exclusion@gmail.com>
2020-10-18 18:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:24 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:30 ` Alexander Lakhin <exclusion@gmail.com>
2020-10-18 18:38 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-18 18:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2020-10-17 13:54 ` Andrew Dunstan <andrew@dunslane.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox