I was looking at this recent nonrepeatable buildfarm failure: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecat&dt=2010-03-11%2021:45:10 which has several instances of the known "pgstat wait timeout" problem during the parallel regression tests.
I was disappointed to see that the postmaster log part of the report is truncated near the start of the run, so there's no way to see if anything interesting got logged near the point of the failure. When I run "make check" on my own OS X machine, I notice that the postmaster.log file usually has some runs of a few dozen null bytes in it. I suspect this is an artifact of Apple's stdio buffering implementation when several backends are writing to the same log file. I suppose that what happened in the above case is that some nulls got embedded in postmaster.log, and then the file got truncated at the first null, perhaps during the upload to the buildfarm server, or maybe it's intact on the server but the web page is failing to display anything past that point. There's probably not much we can do about Apple's stdio (and I would bet that they inherited this behavior from the BSDen anyway). What we *could* do is (1) encourage buildfarm owners to run the tests with logging_collector turned on, and/or (2) fix the buildfarm reporting mechanisms to not be fazed by nulls in the log files. I have no clear idea how hard either of these things is. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers