On Fri, Dec 6, 2019 at 1:30 PM Alexander Lakhin <exclusion@gmail.com> wrote:
>
> 06.12.2019 10:00, PG Bug reporting form wrote:
>
> When performing regression tests on Windows intermittent failures are
> observed, e.g. in src/bin/pg_basebackup test:
> vcregress taptest src/bin/pg_basebackup
> ...
> t/010_pg_basebackup.pl ... 10/106 Bailout called. Further testing stopped:
> system pg_ctl failed
> FAILED--Further testing stopped: system pg_ctl failed
>
>
> waiting for server to start....The process cannot access the file because it
> is being used by another process.
> stopped waiting
> pg_ctl: could not start server
>
> The issue is caused by sporadic "pg_ctl ... restart -l logfile" failures.
>
>
> To reproduce this issue reliably I propose the simple demo patch (delay_after_unlink_pid p, li { white-space:
pre-wrap;).
> With the delay added the "pg_ctl ... restart -l logfile" command (and "vcregress taptest src/bin/pg_basebackup")
failsalways.
> Error message is not very informational, but debugging shows that the file in question is the log file, specified
whenrunning the command:
> "C:\Windows\system32\cmd.exe" /C ""C:/src/postgresql/tmp_install/bin/postgres.exe" -D
"C:/src/postgresql/src/bin/pg_basebackup/tmp_check/t_010_pg_basebackup_main_data/pgdata"--cluster-name=main < "nul" >>
"C:/src/postgresql/src/bin/pg_basebackup/tmp_check/log/010_pg_basebackup_main.log"2>&1"
>
> If this file is still opened by the previous server shell (it can happen when the previous server instance has
unlinkedit's pid file, but it's CMD shell is still running), the next CMD start fails with the aforementioned error
message.
>
What is the reason for the previous shell still accessing logfile?
Is the reason that we don't close it before unlinking the pid file?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
