RE: Intermittent failure with t/003_logical_slots.pl test on windows - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Intermittent failure with t/003_logical_slots.pl test on windows
Date
Msg-id TYAPR01MB5866895F87B08E429BA7FE56F5A7A@TYAPR01MB5866.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Intermittent failure with t/003_logical_slots.pl test on windows  (Nisha Moond <nisha.moond412@gmail.com>)
List pgsql-hackers
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 execute
> 
> Failure, 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].
 
> 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


pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: [PATCH] postgresql.conf.sample comment alignment.
Next
From: Tom Lane
Date:
Subject: Re: EXCLUDE COLLATE in CREATE/ALTER TABLE document