Intermittent failure with t/003_logical_slots.pl test on windows
Hi hackers,
There is a failure with 't/003_logical_slots.pl' test during the
upgrade. The failure is intermittent and observed in the Windows
environment.
Details-
Test - pg_upgrade/t/003_logical_slots.pl
Result -
t/003_logical_slots.pl .. 5/?
# Failed test 'run of pg_upgrade of old cluster'
# at t/003_logical_slots.pl line 165.
t/003_logical_slots.pl .. 10/?
# Failed test 'check the slot exists on new cluster'
# at t/003_logical_slots.pl line 171.
# got: ''
# expected: 'regress_sub|t'
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 25 just after 11.
t/003_logical_slots.pl .. Dubious, test returned 25 (wstat 6400, 0x1900)
Failed 2/11 subtests
Test Summary Report
-------------------
t/003_logical_slots.pl (Wstat: 6400 (exited 25) Tests: 11 Failed: 2)
Failed tests: 10-11
Non-zero exit status: 25
Parse errors: No plan found in TAP output
Files=1, Tests=11, 32 wallclock secs ( 0.03 usr + 0.01 sys = 0.05 CPU)
Result: FAIL
log attached - 'regress_log_003_logical_slots'.
The failure cause is -
no data was returned by command
""D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal" -V"
check for "D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal"
failed: cannot execute
Failure, exiting
[16:24:21.144](6.275s) not ok 10 - run of pg_upgrade of old cluster
If the same command is run manually, it succeeds -
"D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal" -V
pg_resetwal (PostgreSQL) 17devel
The same test failure (intermittent) is also seen with different
commands like pg_ctl and pg_dump as failure cause while retrieving
version -
Ex -
no data was returned by command
""D:/Project/pg1/postgres/tmp_install/bin/pg_dump" -V"
check for "D:/Project/pg1/postgres/tmp_install/bin/pg_dump" failed:
cannot execute
Failure, exiting
[16:08:50.444](7.434s) not ok 10 - run of pg_upgrade of old cluster
Has anyone come across this issue? I am not sure what is the issue here.
Any thoughts?
Thanks,
Nisha Moond
Attachments:
On Tue, Oct 31, 2023 at 4:53 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
There is a failure with 't/003_logical_slots.pl' test during the
upgrade. The failure is intermittent and observed in the Windows
environment.
How did you reach the conclusion that it is only for
't/003_logical_slots.pl'? I see that the failure is while pg_upgrade
internally running pg_resetwal -V command to check the version which
doesn't seem to be directly related to the newly added test or code.
Details-
Test - pg_upgrade/t/003_logical_slots.pl
Result -
t/003_logical_slots.pl .. 5/?
# Failed test 'run of pg_upgrade of old cluster'
# at t/003_logical_slots.pl line 165.
t/003_logical_slots.pl .. 10/?
# Failed test 'check the slot exists on new cluster'
# at t/003_logical_slots.pl line 171.
# got: ''
# expected: 'regress_sub|t'
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 25 just after 11.
t/003_logical_slots.pl .. Dubious, test returned 25 (wstat 6400, 0x1900)
Failed 2/11 subtestsTest Summary Report
-------------------
t/003_logical_slots.pl (Wstat: 6400 (exited 25) Tests: 11 Failed: 2)
Failed tests: 10-11
Non-zero exit status: 25
Parse errors: No plan found in TAP output
Files=1, Tests=11, 32 wallclock secs ( 0.03 usr + 0.01 sys = 0.05 CPU)
Result: FAILlog attached - 'regress_log_003_logical_slots'.
The failure cause is -
no data was returned by command
""D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal" -V"
check for "D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal"
failed: cannot executeFailure, exiting
[16:24:21.144](6.275s) not ok 10 - run of pg_upgrade of old clusterIf the same command is run manually, it succeeds -
Can you add some LOGs in pg_resetwal to find out if the command has
performed appropriately?
--
With Regards,
Amit Kapila.
On Tue, 31 Oct 2023 at 17:51, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Tue, Oct 31, 2023 at 4:53 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
There is a failure with 't/003_logical_slots.pl' test during the
upgrade. The failure is intermittent and observed in the Windows
environment.How did you reach the conclusion that it is only for
't/003_logical_slots.pl'? I see that the failure is while pg_upgrade
internally running pg_resetwal -V command to check the version which
doesn't seem to be directly related to the newly added test or code.
I also felt it is not related to the 003_logical_slots test, I felt
the problem might be because of the pipe_read_line function:
....
pipe_read_line(char *cmd, char *line, int maxsize)
{
FILE *pgver;
fflush(NULL);
errno = 0;
if ((pgver = popen(cmd, "r")) == NULL)
{
perror("popen failure");
return NULL;
}
errno = 0;
if (fgets(line, maxsize, pgver) == NULL)
...
Few others are also facing this problem with similar code like in:
https://stackoverflow.com/questions/15882799/fgets-returning-error-for-file-returned-by-popen
Regards,
Vignesh
Dear Nisha,
The failure cause is -
no data was returned by command
""D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal" -V"
check for "D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal"
failed: cannot executeFailure, exiting
[16:24:21.144](6.275s) not ok 10 - run of pg_upgrade of old cluster
I thought it was not related with the feature. I doubt the pg_upgrade read the
command result before it was really executed.
First of all, The stack trace until the system call _popen() is as follows.
```
check_exec()
pipe_read_line()
popen()
pgwin32_popen()
_popen() // process was forked and command would be executed
```
I read MSdocs and said that _popen executes specified commands asynchronously [1]https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/popen-wpopen?view=msvc-170.
The _popen function creates a pipe. It then asynchronously executes a spawned
copy of the command processor, and uses command as the command line.
Your failure meant that the binary was found but its output was not found by fgets().
So I thought that the forked process has not executed the command yet at that time. Thought?
[1]: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/popen-wpopen?view=msvc-170
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
At Tue, 31 Oct 2023 18:11:48 +0530, vignesh C <vignesh21@gmail.com> wrote in
Few others are also facing this problem with similar code like in:
https://stackoverflow.com/questions/15882799/fgets-returning-error-for-file-returned-by-popen
I'm inclined to believe that the pipe won't enter the EOF state until
the target command terminates (then the top-level cmd.exe). The target
command likely terminated prematurely due to an error before priting
any output.
If we append "2>&1" to the command line, we can capture the error
message through the returned pipe if any. Such error messages will
cause the subsequent code to fail with an error such as "unexpected
string: 'the output'". I'm not sure, but if this is permissive, the
returned error messages could potentially provide insight into the
underlying issue, paving the way for a potential solution.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
On Thu, Nov 2, 2023 at 11:52 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
At Tue, 31 Oct 2023 18:11:48 +0530, vignesh C <vignesh21@gmail.com> wrote in
Few others are also facing this problem with similar code like in:
https://stackoverflow.com/questions/15882799/fgets-returning-error-for-file-returned-by-popenI'm inclined to believe that the pipe won't enter the EOF state until
the target command terminates (then the top-level cmd.exe). The target
command likely terminated prematurely due to an error before priting
any output.If we append "2>&1" to the command line, we can capture the error
message through the returned pipe if any. Such error messages will
cause the subsequent code to fail with an error such as "unexpected
string: 'the output'". I'm not sure, but if this is permissive, the
returned error messages could potentially provide insight into the
underlying issue, paving the way for a potential solution.
Appending '2>&1 test:
The command still results in NULL and ends up failing as no data is
returned. Which means even no error message is returned. The error log
with appended '2>$1' is -
no data was returned by command
""D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal" -V 2>&1"
check for "D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal"
failed: cannot execute
Failure, exiting
Further observations:
1. To make sure the forked process completes before fgets(), I tested
with Sleep(100) before fgets() call.
...
...
if ((pgver = popen(cmd, "r")) == NULL)
{
perror("popen failure");
return NULL;
}
errno = 0;
Sleep(100);
if (fgets(line, maxsize, pgver) == NULL)
{
if (feof(pgver))
fprintf(stderr, "no data was returned by command \"%s\"\n", cmd);
...
...
This also doesn't resolve the issue, the error is still seen intermittently.
2. Even though fgets() fails, the output is still getting captured in
'line' string.
Tested with printing the 'line' in case of failure:
...
...
if ((pgver = popen(cmd, "r")) == NULL)
{
perror("popen failure");
return NULL;
}
errno = 0;
if (fgets(line, maxsize, pgver) == NULL)
{
if (line)
fprintf(stderr, "cmd output - %s\n", line);
if (feof(pgver))
fprintf(stderr, "no data was returned by command \"%s\"\n", cmd);
…
…
And the log looks like -
cmd output - postgres (PostgreSQL) 17devel
no data was returned by command
""D:/Project/pg1/postgres/tmp_install/bin/pg_controldata" -V"
check for "D:/Project/pg1/postgres/tmp_install/bin/pg_controldata"
failed: cannot execute
Failure, exiting
Attached test result log for the same - "regress_log_003_logical_slots".
Thanks,
Nisha Moond
Attachments:
On Fri, Nov 3, 2023 at 5:02 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
On Thu, Nov 2, 2023 at 11:52 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:At Tue, 31 Oct 2023 18:11:48 +0530, vignesh C <vignesh21@gmail.com> wrote in
Few others are also facing this problem with similar code like in:
https://stackoverflow.com/questions/15882799/fgets-returning-error-for-file-returned-by-popenI'm inclined to believe that the pipe won't enter the EOF state until
the target command terminates (then the top-level cmd.exe). The target
command likely terminated prematurely due to an error before priting
any output.If we append "2>&1" to the command line, we can capture the error
message through the returned pipe if any. Such error messages will
cause the subsequent code to fail with an error such as "unexpected
string: 'the output'". I'm not sure, but if this is permissive, the
returned error messages could potentially provide insight into the
underlying issue, paving the way for a potential solution.Appending '2>&1 test:
The command still results in NULL and ends up failing as no data is
returned. Which means even no error message is returned. The error log
with appended '2>$1' is -no data was returned by command
""D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal" -V 2>&1"check for "D:/Project/pg1/postgres/tmp_install/bin/pg_resetwal"
failed: cannot execute
Failure, exitingFurther observations:
1. To make sure the forked process completes before fgets(), I tested
with Sleep(100) before fgets() call.
...
...
if ((pgver = popen(cmd, "r")) == NULL)
{
perror("popen failure");
return NULL;
}errno = 0;
Sleep(100);
if (fgets(line, maxsize, pgver) == NULL)
{
if (feof(pgver))
fprintf(stderr, "no data was returned by command \"%s\"\n", cmd);
...
...This also doesn't resolve the issue, the error is still seen intermittently.
2. Even though fgets() fails, the output is still getting captured in
'line' string.
Tested with printing the 'line' in case of failure:
...
...
if ((pgver = popen(cmd, "r")) == NULL)
{
perror("popen failure");
return NULL;
}errno = 0;
if (fgets(line, maxsize, pgver) == NULL)
{
if (line)
fprintf(stderr, "cmd output - %s\n", line);if (feof(pgver))
fprintf(stderr, "no data was returned by command \"%s\"\n", cmd);
…
…
And the log looks like -
cmd output - postgres (PostgreSQL) 17devel
no data was returned by command
""D:/Project/pg1/postgres/tmp_install/bin/pg_controldata" -V"check for "D:/Project/pg1/postgres/tmp_install/bin/pg_controldata"
failed: cannot execute
Failure, exitingAttached test result log for the same - "regress_log_003_logical_slots".
The same failure is observed with test 't\002_pg_upgrade.pl' too
(intermittently). So, it is not limited to "t/003_logical_slots.pl"
test alone. It is more closely associated with the pg_upgrade command
run.
--
Thanks,
Nisha Moond
At Mon, 6 Nov 2023 19:42:21 +0530, Nisha Moond <nisha.moond412@gmail.com> wrote in
Appending '2>&1 test:
The command still results in NULL and ends up failing as no data is
returned. Which means even no error message is returned. The error log
Thanks for confirmation. So, at least the child process was launced
successfully in the cmd.exe's view.
Upon a quick check on my end with Windows' _popen, I have obseved the
following:
- Once a child process is started, it seems to go undetected as an
error by _popen or subsequent fgets calls if the process ends
abnormally, with a non-zero exit status or even with a SEGV.
- After the child process has flushed data to stdout, it is possible
to read from the pipe even if the child process crashes or ends
thereafter.
- Even if fgets is called before the program starts, it will correctly
block until the program outputs something. Specifically, when I used
popen("sleep 5 & target.exe") and immediately performed fgets on the
pipe, I was able to read the output of target.exe as the first line.
Therefore, based on the information available, it is conceivable that
the child process was killed by something right after it started, or
the program terminated on its own without any error messages.
By the way, in the case of aforementioned SEGV, Application Errors
corresponding to it were identifiable in the Event
Viewer. Additionally, regarding the exit statuses, they can be
captured by using a wrapper batch file (.bat) that records
%ERRORLEVEL% after running the target program. This may yield
insights, aothough its effectiveness is not guaranteed.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Hi,
The same intermittent failure is reproducible on my system.
For the intermittent issues I found that many issues are due to errors
where commands like 'psql -V' are not returning any output.
To reproduce it in an easy way, I wrote a script (.bat file) with
'--version' option for different binaries. And found out that it was
not giving any output for some command (varies for each run).
Then I tried to run the same script after adding 'fflush(stdout)' in
the function called with '--version' option and it started to give
output for each command.
I noticed the same for '--help' option and did the changes for the same.
I have attached the test script(changes the extension to .txt as gmail
is blocking it), output of test before the changes.
I have also attached the patch with changes which resolved the above issue.
This change has resolved most of the intermittent issues for me. I am
facing some more intermittent issues. Will analyse and share it as
well.
Thanks and regards
Shlok Kyal
Show quoted text
On Tue, 7 Nov 2023 at 11:05, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
At Mon, 6 Nov 2023 19:42:21 +0530, Nisha Moond <nisha.moond412@gmail.com> wrote in
Appending '2>&1 test:
The command still results in NULL and ends up failing as no data is
returned. Which means even no error message is returned. The error logThanks for confirmation. So, at least the child process was launced
successfully in the cmd.exe's view.Upon a quick check on my end with Windows' _popen, I have obseved the
following:- Once a child process is started, it seems to go undetected as an
error by _popen or subsequent fgets calls if the process ends
abnormally, with a non-zero exit status or even with a SEGV.- After the child process has flushed data to stdout, it is possible
to read from the pipe even if the child process crashes or ends
thereafter.- Even if fgets is called before the program starts, it will correctly
block until the program outputs something. Specifically, when I used
popen("sleep 5 & target.exe") and immediately performed fgets on the
pipe, I was able to read the output of target.exe as the first line.Therefore, based on the information available, it is conceivable that
the child process was killed by something right after it started, or
the program terminated on its own without any error messages.By the way, in the case of aforementioned SEGV, Application Errors
corresponding to it were identifiable in the Event
Viewer. Additionally, regarding the exit statuses, they can be
captured by using a wrapper batch file (.bat) that records
%ERRORLEVEL% after running the target program. This may yield
insights, aothough its effectiveness is not guaranteed.regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachments:
v1-0001-Fix-Windows-Intermittent-Failure.patchapplication/octet-stream; name=v1-0001-Fix-Windows-Intermittent-Failure.patchDownload
From 4a079bfee90a41efc5cc12141c32e438c4754ef2 Mon Sep 17 00:00:00 2001
From: Shlok Kyal <shlok.kyal@gmail.com>
Date: Tue, 26 Dec 2023 17:02:59 +0530
Subject: [PATCH v1] Fix Windows Intermittent Failure
When tests are run on Windows using meson, some tests fails
intermittently. With this fix those intermittent failures
are resolved.
---
contrib/oid2name/oid2name.c | 2 ++
contrib/vacuumlo/vacuumlo.c | 2 ++
src/backend/main/main.c | 2 ++
src/bin/initdb/initdb.c | 2 ++
src/bin/pg_archivecleanup/pg_archivecleanup.c | 2 ++
src/bin/pg_basebackup/pg_basebackup.c | 2 ++
src/bin/pg_basebackup/pg_receivewal.c | 2 ++
src/bin/pg_basebackup/pg_recvlogical.c | 2 ++
src/bin/pg_checksums/pg_checksums.c | 2 ++
src/bin/pg_config/pg_config.c | 1 +
src/bin/pg_controldata/pg_controldata.c | 2 ++
src/bin/pg_ctl/pg_ctl.c | 2 ++
src/bin/pg_dump/pg_dump.c | 2 ++
src/bin/pg_dump/pg_dumpall.c | 2 ++
src/bin/pg_dump/pg_restore.c | 2 ++
src/bin/pg_resetwal/pg_resetwal.c | 2 ++
src/bin/pg_rewind/pg_rewind.c | 2 ++
src/bin/pg_test_fsync/pg_test_fsync.c | 2 ++
src/bin/pg_test_timing/pg_test_timing.c | 2 ++
src/bin/pg_upgrade/option.c | 2 ++
src/bin/pg_verifybackup/pg_verifybackup.c | 2 ++
src/bin/pg_waldump/pg_waldump.c | 2 ++
src/bin/pgbench/pgbench.c | 2 ++
src/bin/psql/startup.c | 3 +++
src/fe_utils/option_utils.c | 2 ++
src/interfaces/ecpg/preproc/ecpg.c | 2 ++
26 files changed, 52 insertions(+)
diff --git a/contrib/oid2name/oid2name.c b/contrib/oid2name/oid2name.c
index e8c1e2c97b..64c5e2c8ae 100644
--- a/contrib/oid2name/oid2name.c
+++ b/contrib/oid2name/oid2name.c
@@ -106,11 +106,13 @@ get_opts(int argc, char **argv, struct options *my_opts)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
help(progname);
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("oid2name (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/contrib/vacuumlo/vacuumlo.c b/contrib/vacuumlo/vacuumlo.c
index e02d84cc96..29eaa38e10 100644
--- a/contrib/vacuumlo/vacuumlo.c
+++ b/contrib/vacuumlo/vacuumlo.c
@@ -476,11 +476,13 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage(progname);
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("vacuumlo (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/backend/main/main.c b/src/backend/main/main.c
index ed11e8be7f..21bc7c1a40 100644
--- a/src/backend/main/main.c
+++ b/src/backend/main/main.c
@@ -146,11 +146,13 @@ main(int argc, char *argv[])
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
help(progname);
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
fputs(PG_BACKEND_VERSIONSTR, stdout);
+ fflush(stdout);
exit(0);
}
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index e68b40d2b5..750b1ee05d 100644
--- a/src/bin/initdb/initdb.c
+++ b/src/bin/initdb/initdb.c
@@ -3140,11 +3140,13 @@ main(int argc, char *argv[])
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage(progname);
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("initdb (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_archivecleanup/pg_archivecleanup.c b/src/bin/pg_archivecleanup/pg_archivecleanup.c
index 2c3b301f3b..8122f033ab 100644
--- a/src/bin/pg_archivecleanup/pg_archivecleanup.c
+++ b/src/bin/pg_archivecleanup/pg_archivecleanup.c
@@ -303,11 +303,13 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_archivecleanup (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_basebackup/pg_basebackup.c b/src/bin/pg_basebackup/pg_basebackup.c
index 5795b91261..c8cebcedea 100644
--- a/src/bin/pg_basebackup/pg_basebackup.c
+++ b/src/bin/pg_basebackup/pg_basebackup.c
@@ -2404,12 +2404,14 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
+ fflush(stdout);
exit(0);
}
else if (strcmp(argv[1], "-V") == 0
|| strcmp(argv[1], "--version") == 0)
{
puts("pg_basebackup (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_basebackup/pg_receivewal.c b/src/bin/pg_basebackup/pg_receivewal.c
index d0a4079d50..ce0d5a168d 100644
--- a/src/bin/pg_basebackup/pg_receivewal.c
+++ b/src/bin/pg_basebackup/pg_receivewal.c
@@ -667,12 +667,14 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
+ fflush(stdout);
exit(0);
}
else if (strcmp(argv[1], "-V") == 0 ||
strcmp(argv[1], "--version") == 0)
{
puts("pg_receivewal (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_basebackup/pg_recvlogical.c b/src/bin/pg_basebackup/pg_recvlogical.c
index 9fe4ac8126..2eb00c9a24 100644
--- a/src/bin/pg_basebackup/pg_recvlogical.c
+++ b/src/bin/pg_basebackup/pg_recvlogical.c
@@ -736,12 +736,14 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
+ fflush(stdout);
exit(0);
}
else if (strcmp(argv[1], "-V") == 0 ||
strcmp(argv[1], "--version") == 0)
{
puts("pg_recvlogical (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_checksums/pg_checksums.c b/src/bin/pg_checksums/pg_checksums.c
index 19c083be17..46a0b1d6ff 100644
--- a/src/bin/pg_checksums/pg_checksums.c
+++ b/src/bin/pg_checksums/pg_checksums.c
@@ -455,11 +455,13 @@ main(int argc, char *argv[])
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_checksums (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_config/pg_config.c b/src/bin/pg_config/pg_config.c
index 70cab817dd..588faf67a9 100644
--- a/src/bin/pg_config/pg_config.c
+++ b/src/bin/pg_config/pg_config.c
@@ -145,6 +145,7 @@ main(int argc, char **argv)
if (strcmp(argv[i], "--help") == 0 || strcmp(argv[i], "-?") == 0)
{
help();
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_controldata/pg_controldata.c b/src/bin/pg_controldata/pg_controldata.c
index 93e0837947..891bf10521 100644
--- a/src/bin/pg_controldata/pg_controldata.c
+++ b/src/bin/pg_controldata/pg_controldata.c
@@ -116,11 +116,13 @@ main(int argc, char *argv[])
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage(progname);
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_controldata (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_ctl/pg_ctl.c b/src/bin/pg_ctl/pg_ctl.c
index 3b145bd838..225537c415 100644
--- a/src/bin/pg_ctl/pg_ctl.c
+++ b/src/bin/pg_ctl/pg_ctl.c
@@ -2231,11 +2231,13 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
do_help();
+ fflush(stdout);
exit(0);
}
else if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_ctl (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 8c0b5486b9..6773726a64 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -457,11 +457,13 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
help(progname);
+ fflush(stdout);
exit_nicely(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_dump (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit_nicely(0);
}
}
diff --git a/src/bin/pg_dump/pg_dumpall.c b/src/bin/pg_dump/pg_dumpall.c
index 92389353a4..fefe02bb2e 100644
--- a/src/bin/pg_dump/pg_dumpall.c
+++ b/src/bin/pg_dump/pg_dumpall.c
@@ -212,11 +212,13 @@ main(int argc, char *argv[])
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
help();
+ fflush(stdout);
exit_nicely(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_dumpall (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit_nicely(0);
}
}
diff --git a/src/bin/pg_dump/pg_restore.c b/src/bin/pg_dump/pg_restore.c
index c3beacdec1..e9b5e478d0 100644
--- a/src/bin/pg_dump/pg_restore.c
+++ b/src/bin/pg_dump/pg_restore.c
@@ -145,11 +145,13 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage(progname);
+ fflush(stdout);
exit_nicely(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_restore (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit_nicely(0);
}
}
diff --git a/src/bin/pg_resetwal/pg_resetwal.c b/src/bin/pg_resetwal/pg_resetwal.c
index 5407f51a4e..3f00bdca6e 100644
--- a/src/bin/pg_resetwal/pg_resetwal.c
+++ b/src/bin/pg_resetwal/pg_resetwal.c
@@ -128,11 +128,13 @@ main(int argc, char *argv[])
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_resetwal (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_rewind/pg_rewind.c b/src/bin/pg_rewind/pg_rewind.c
index f55ef4f2f8..87eb46b3c6 100644
--- a/src/bin/pg_rewind/pg_rewind.c
+++ b/src/bin/pg_rewind/pg_rewind.c
@@ -164,11 +164,13 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage(progname);
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_rewind (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_test_fsync/pg_test_fsync.c b/src/bin/pg_test_fsync/pg_test_fsync.c
index 54bc0767f1..2805f6befd 100644
--- a/src/bin/pg_test_fsync/pg_test_fsync.c
+++ b/src/bin/pg_test_fsync/pg_test_fsync.c
@@ -163,11 +163,13 @@ handle_args(int argc, char *argv[])
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
printf(_("Usage: %s [-f FILENAME] [-s SECS-PER-TEST]\n"), progname);
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_test_fsync (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_test_timing/pg_test_timing.c b/src/bin/pg_test_timing/pg_test_timing.c
index c29d6f8762..33e53bb7ab 100644
--- a/src/bin/pg_test_timing/pg_test_timing.c
+++ b/src/bin/pg_test_timing/pg_test_timing.c
@@ -57,11 +57,13 @@ handle_args(int argc, char *argv[])
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
printf(_("Usage: %s [-d DURATION]\n"), progname);
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_test_timing (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_upgrade/option.c b/src/bin/pg_upgrade/option.c
index b9d900d0db..1a3e59fed9 100644
--- a/src/bin/pg_upgrade/option.c
+++ b/src/bin/pg_upgrade/option.c
@@ -90,11 +90,13 @@ parseCommandLine(int argc, char *argv[])
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_upgrade (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_verifybackup/pg_verifybackup.c b/src/bin/pg_verifybackup/pg_verifybackup.c
index 88081f66f7..12d79976b3 100644
--- a/src/bin/pg_verifybackup/pg_verifybackup.c
+++ b/src/bin/pg_verifybackup/pg_verifybackup.c
@@ -203,11 +203,13 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_verifybackup (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pg_waldump/pg_waldump.c b/src/bin/pg_waldump/pg_waldump.c
index a3535bdfa9..ab667e8c29 100644
--- a/src/bin/pg_waldump/pg_waldump.c
+++ b/src/bin/pg_waldump/pg_waldump.c
@@ -840,11 +840,13 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pg_waldump (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 2e1650d0ad..96c0e081f0 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -6684,11 +6684,13 @@ main(int argc, char **argv)
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
puts("pgbench (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/bin/psql/startup.c b/src/bin/psql/startup.c
index 78526eb9da..3b543228fa 100644
--- a/src/bin/psql/startup.c
+++ b/src/bin/psql/startup.c
@@ -140,11 +140,13 @@ main(int argc, char *argv[])
if ((strcmp(argv[1], "-?") == 0) || (argc == 2 && (strcmp(argv[1], "--help") == 0)))
{
usage(NOPAGER);
+ fflush(stdout);
exit(EXIT_SUCCESS);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
showVersion();
+ fflush(stdout);
exit(EXIT_SUCCESS);
}
}
@@ -839,6 +841,7 @@ static void
showVersion(void)
{
puts("psql (PostgreSQL) " PG_VERSION);
+ fflush(stdout);
}
diff --git a/src/fe_utils/option_utils.c b/src/fe_utils/option_utils.c
index d2a3adeb4b..983804c935 100644
--- a/src/fe_utils/option_utils.c
+++ b/src/fe_utils/option_utils.c
@@ -29,11 +29,13 @@ handle_help_version_opts(int argc, char *argv[],
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
hlp(get_progname(argv[0]));
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
printf("%s (PostgreSQL) " PG_VERSION "\n", fixed_progname);
+ fflush(stdout);
exit(0);
}
}
diff --git a/src/interfaces/ecpg/preproc/ecpg.c b/src/interfaces/ecpg/preproc/ecpg.c
index 16cfc49e5e..54099b02eb 100644
--- a/src/interfaces/ecpg/preproc/ecpg.c
+++ b/src/interfaces/ecpg/preproc/ecpg.c
@@ -147,11 +147,13 @@ main(int argc, char *const argv[])
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
help(progname);
+ fflush(stdout);
exit(0);
}
if (strcmp(argv[1], "--version") == 0 || strcmp(argv[1], "-V") == 0)
{
printf("ecpg (PostgreSQL) %s\n", PG_VERSION);
+ fflush(stdout);
exit(0);
}
}
--
2.41.0.windows.3
Thanks for working on it. I tested the patch on my system and it
resolved the issue with commands running -V (version check).
As you mentioned, I am also still seeing intermittent errors even with
the patch as below -
in 'pg_upgrade/002_pg_upgrade' -
# Running: pg_upgrade --no-sync -d
D:\Project\pg2\postgres\build/testrun/pg_upgrade/002_pg_upgrade\data/t_002_pg_upgrade_old_node_data/pgdata
-D D:\Project\pg2\postgres\build/testrun/pg_upgrade/002_pg_upgrade\data/t_002_pg_upgrade_new_node_data/pgdata
-b D:/Project/pg2/postgres/build/tmp_install/Project/pg2/postgresql/bin
-B D:/Project/pg2/postgres/build/tmp_install/Project/pg2/postgresql/bin
-s 127.0.0.1 -p 56095 -P 56096 --copy --check
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
The source cluster lacks cluster state information:
Failure, exiting
[12:37:38.666](3.317s) not ok 12 - run of pg_upgrade --check for new instance
[12:37:38.666](0.000s) # Failed test 'run of pg_upgrade --check for
new instance'
# at D:/Project/pg2/postgres/src/bin/pg_upgrade/t/002_pg_upgrade.pl line 375.
and in 'pg_upgrade/003_logical_slots' -
[12:35:33.773](0.001s) not ok 6 - run of pg_upgrade of old cluster
with slots having unconsumed WAL records stdout /(?^:Your installation
contains logical replication slots that can't be upgraded.)/
[12:35:33.773](0.000s) # Failed test 'run of pg_upgrade of old
cluster with slots having unconsumed WAL records stdout /(?^:Your
installation contains logical replication slots that can't be
upgraded.)/'
# at D:/Project/pg2/postgres/src/bin/pg_upgrade/t/003_logical_slots.pl
line 102.
[12:35:33.773](0.000s) # 'Performing Consistency Checks
# -----------------------------
# Checking cluster versions ok
#
# The target cluster lacks cluster state information:
# Failure, exiting
It seems 'Performing Consistency Checks' fail due to a lack of some
information and possible that it can also be fixed on the same lines.
--
Thanks,
Nisha
Hi,
Apart of these I am getting following some intermittent failure as below:
131/272 postgresql:pg_basebackup / pg_basebackup/010_pg_basebackup
ERROR 30.51s (exit status 255 or
signal 127 SIGinvalid)
114/272 postgresql:libpq / libpq/001_uri
ERROR 9.66s exit status 8
34/272 postgresql:pg_upgrade / pg_upgrade/003_logical_slots
ERROR 99.14s exit status 1
186/272 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade
ERROR 306.22s exit status 1
29/272 postgresql:recovery / recovery/002_archiving
ERROR 89.62s (exit status 255 or
signal 127 SIGinvalid)
138/272 postgresql:pg_resetwal / pg_resetwal/001_basic
ERROR 3.93s (exit status 255 or
signal 127 SIGinvalid)
Have attached the regress logs for the same as well.
Thanks and Regards
Shlok Kyal
Show quoted text
On Tue, 26 Dec 2023 at 17:39, Shlok Kyal <shlok.kyal.oss@gmail.com> wrote:
Hi,
The same intermittent failure is reproducible on my system.
For the intermittent issues I found that many issues are due to errors
where commands like 'psql -V' are not returning any output.
To reproduce it in an easy way, I wrote a script (.bat file) with
'--version' option for different binaries. And found out that it was
not giving any output for some command (varies for each run).
Then I tried to run the same script after adding 'fflush(stdout)' in
the function called with '--version' option and it started to give
output for each command.
I noticed the same for '--help' option and did the changes for the same.I have attached the test script(changes the extension to .txt as gmail
is blocking it), output of test before the changes.
I have also attached the patch with changes which resolved the above issue.This change has resolved most of the intermittent issues for me. I am
facing some more intermittent issues. Will analyse and share it as
well.Thanks and regards
Shlok KyalOn Tue, 7 Nov 2023 at 11:05, Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
At Mon, 6 Nov 2023 19:42:21 +0530, Nisha Moond <nisha.moond412@gmail.com> wrote in
Appending '2>&1 test:
The command still results in NULL and ends up failing as no data is
returned. Which means even no error message is returned. The error logThanks for confirmation. So, at least the child process was launced
successfully in the cmd.exe's view.Upon a quick check on my end with Windows' _popen, I have obseved the
following:- Once a child process is started, it seems to go undetected as an
error by _popen or subsequent fgets calls if the process ends
abnormally, with a non-zero exit status or even with a SEGV.- After the child process has flushed data to stdout, it is possible
to read from the pipe even if the child process crashes or ends
thereafter.- Even if fgets is called before the program starts, it will correctly
block until the program outputs something. Specifically, when I used
popen("sleep 5 & target.exe") and immediately performed fgets on the
pipe, I was able to read the output of target.exe as the first line.Therefore, based on the information available, it is conceivable that
the child process was killed by something right after it started, or
the program terminated on its own without any error messages.By the way, in the case of aforementioned SEGV, Application Errors
corresponding to it were identifiable in the Event
Viewer. Additionally, regarding the exit statuses, they can be
captured by using a wrapper batch file (.bat) that records
%ERRORLEVEL% after running the target program. This may yield
insights, aothough its effectiveness is not guaranteed.regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center