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;
>>
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^\

>>
>> @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@[53cd99ba.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