Re: Cygwin PostgreSQL Regression Test Problems (Revisited)

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> I previously reported the above problem with the parallel version of
> the regression test (i.e., make check) on a machine with limited memory.
> Unfortunately, I am seeing similar problems on a machine with 192 MB of
> physical memory and about 208 MB of swap space. So, now I feel that my
> initial conclusion that limited memory was the root cause is erroneous.

Not necessarily. 18 parallel tests imply 54 concurrent processes
(a shell, a psql, and a backend per test). Depending on whether Windoze
is any good about sharing sharable pages across processes, it's not hard
at all to believe that each process might chew up a few meg of memory
and/or swap. You don't have a whole lot of headroom there if so.

Try modifying the parallel_schedule file to break the largest set of
concurrent tests down into two sets of nine tests.

Considering that we've seen people run into maxuprc limits on some Unix
versions, I wonder whether we ought to just do that across-the-board.

> What is the best way to "catch" this problem? What are the best set of
> options to pass to postmaster that will be in turn passed to the back-end
> postgres processes to hopefully shed some light on this situation?

I'd use -d1 which should be enough to see backends starting and exiting.
Any more will clutter the log with individual queries, which probably
would be more detail than you really want...

regards, tom lane