I wrote: > Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >> The problem is command_like's use of redirection to strings. Why this >> should be a problem for this particular use is a matter of speculation.
> I looked at jacana's two recent pg_ctlCheck failures, and they both > seem to have failed on this: > command_like([ 'pg_ctl', 'start', '-D', "$tempdir/data", > '-l', "$TestLib::log_path/001_start_stop_server.log" ], > qr/done.*server started/s, 'pg_ctl start'); > That is redirecting the postmaster's stdout/stderr into a file, > for sure, so the child processes shouldn't impact EOF detection AFAICS. > It's also hard to explain this way why it only fails some of the time. I reflected a bit more on this issue, and realized that there's a pretty obvious mechanism for this to happen. While on Unix, we have pg_ctl fork-and-exec the postmaster so that no extra processes are laying about, that's not the case on Windows. The Windows code in pg_ctl.c creates a subprocess that runs CMD.EXE, which in turn runs the postmaster as a subprocess. The CMD.EXE process doesn't disappear until the postmaster exits. Now, we tell CMD to redirect the postmaster's stdout and stderr into files, but there's no way to tell CMD to redirect its own handles. So if the CMD process inherits pg_ctl's stdout and stderr, then the prove process would not see EOF on those pipes after pg_ctl exits. Now, this theory still has a Mack-truck-sized hole in it, which is if that's the failure mechanism then why isn't it 100% effective? Seems like the TAP test should fail every time, if this is a full description. But maybe it's part of the answer, so it seems worth experimenting in this direction. A bit of googling Microsoft's documentation suggests that maybe all we have to do is pass CreateProcessAsUser's bInheritHandles parameter as FALSE not TRUE in pg_ctl.c. It's not apparent to me that there are any handles we do need the CMD process to inherit. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers