Andrew Dunstan wrote:
> Andrew Dunstan wrote:
>
>>
>> still investigating ...
>>
>
> The log traces (log_connections=true, log_disconnections=true,
> log_statement='all') show that if I run without limiting
> max_connections, the next tests start up before the copy is finished -
> no wonder things get right royally screwed as a result.
>
> It seems like the problem is in the Msys shell. It appears not to wait
> correctly for a job to finish (Single tests are run in the foreground
> by the shell, so no explicit 'wait' is run - I tried putting one in
> with no effect). It's probably triggered by the copy test because it
> takes such a long time. I have no idea why the parallelism of the
> tests should affect it.
>
> trying to find a workaround.
>
OK. The workaround that I have just come up with worked has just worked
in 6 successive runs of "make check" and friends under MSys, so I'm
prepared to declare a win and start preparing patches. It will be next
week before I can get that done.
The workaround is to run the single command in a background shell and
wait for it, just like the parallel tests.
Here is a summary of the diffs in my tree:
. configure.in
- checks at the end to make sure that links have built properly and
warns if not
. src/bin
- added pgkill based in the one on the web page, with a Makefile and
install target
. src/bin/psql/print.c
- suppress newline after footers for win32, as previously discussed
. src/test/regress/GNUmakefile
- added a target pinstallcheck to run against an installed and
running server, but using the parallel tests
- add a test to the sed command to make sure the files were built
correctly
. src/test/pg_regress.sh
- see previous post and above
- also calls pgkill under mingw instead of kill -15, which doesn't
work. Gets the pid for pgkill from postmaster.pid.
. src/test/regress/expected/join-win32.out
- new file reflecting different order from join results on win32
. src/test/regress/resultmap.out
- maps above for win32
The pgkill stuff is pending us getting a binary pg_ctl. But it seems to
work very well.
With all these changes I now consistently get 94 of 94 tests passing,
and a completely clean (and automatic) server shutdown.
cheers
andrew