Re: Some bogus results from prairiedog

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Some bogus results from prairiedog
Date: 2014-07-22 14:55:17
Message-ID: 53CE7B55.1080505@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabrízio de Royes Mello 2014-07-22 15:01:59 Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Previous Message Tom Lane 2014-07-22 14:54:06 Re: [bug fix] Suppress "autovacuum: found orphan temp table" message