Re: Some bogus results from prairiedog

On 07/22/2014 10:55 AM, Andrew Dunstan wrote:
>
> On 07/22/2014 12:24 AM, Tom Lane wrote:
>> According to
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2014-07-21%2022%3A36%3A55
>>
>> prairiedog saw a crash in "make check" on the 9.4 branch earlier
>> tonight;
>> but there's not a lot of evidence as to why in the buildfarm report,
>> because the postmaster log file is truncated well before where things
>> got
>> interesting. Fortunately, I was able to capture a copy of check.log
>> before it got overwritten by the next run. I find that the place where
>> the webserver report stops matches this section of check.log:
>>
>> [53cd99bb.134a:158] LOG: statement: create index test_range_gist_idx
>> on test_range_gist using gist (ir);
>> [53cd99bb.134a:159] LOG: statement: insert into test_range_gist
>> select int4range(g, g+10) from generate_series(1,2000) g;
>> ^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^\
>>
>> @^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)^@^(at)[53cd99ba(dot)1344:329] LOG:
>> statement: INSERT INTO num_exp_div VALUES
>> (7,8,'-1108.80577182462841041118');
>> [53cd99ba.1344:330] LOG: statement: INSERT INTO num_exp_add VALUES
>> (7,9,'-107955289.045047420');
>> [53cd99ba.1344:331] LOG: statement: INSERT INTO num_exp_sub VALUES
>> (7,9,'-58101680.954952580');
>>
>> The ^@'s represent nul bytes, which I find runs of elsewhere in the file
>> as well. I think they are an artifact of OS X buffering policy
>> caused by
>> multiple processes writing into the same file without any interlocks.
>> Perhaps we ought to consider making buildfarm runs use the logging
>> collector by default? But in any case, it seems uncool that either the
>> buildfarm log-upload process, or the buildfarm web server, is unable to
>> cope with log files containing nul bytes.
>
>
> The data is there, just click on the "check" stage link at the top of
> the page to see it in raw form.
>
>

I have made a change in the upload receiver app to escape nul bytes in
the main log field too. This will operate prospectively.

Using the logging collector would be a larger change, but we can look at
it if this isn't sufficient.

cheers

andrew