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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
