On Fri, Nov 3, 2023 at 5:02 PM Nisha Moond <nisha.moond...@gmail.com> wrote: > > On Thu, Nov 2, 2023 at 11:52 AM Kyotaro Horiguchi > <horikyota....@gmail.com> wrote: > > > > At Tue, 31 Oct 2023 18:11:48 +0530, vignesh C <vignes...@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. > > > > 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".
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