Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I was looking at this recent nonrepeatable buildfarm failure:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecatdt=2010-03-11%2021:45:10
Well, the good news is that we actually have the data on the server, in
a temp file
Tom Lane wrote:
Most of the pgstat wait timeout gripes are coming from the backend
running the vacuum regression test, but there are two that came from
process dcc0, which is shown by other log entries to be the autovacuum
launcher. So now I'm wondering if there could be some issue that
Tom Lane wrote:
Now, the log_text field in our build_status_log table is text, so it's
on insertion to the database that it gets truncated. I'm thinking that I
should just escape nulls with a regex ( 's/\x00/\\0/g' or similar)
before inserting the data.
Works for me.
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Most of the pgstat wait timeout gripes are coming from the backend
running the vacuum regression test, but there are two that came from
process dcc0, which is shown by other log entries to be the autovacuum
launcher. So now
Robert Creager wrote:
On Mar 11, 2010, at 6:00 PM, Andrew Dunstan wrote:
Tom Lane wrote:
I was looking at this recent nonrepeatable buildfarm failure:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecatdt=2010-03-11%2021:45:10
which has several instances of the known
Robert Creager rob...@logicalchaos.org writes:
Is there any value in setting keep_error_builds = 0,? I know Andrew was
able to get the complete log file.
The data is all uploaded to the buildfarm server, so as long as EDB
doesn't holler uncle about the amount of storage that's taking, I don't
Tom Lane wrote:
Robert Creager rob...@logicalchaos.org writes:
Is there any value in setting keep_error_builds = 0,? I know Andrew was
able to get the complete log file.
The data is all uploaded to the buildfarm server, so as long as EDB
doesn't holler uncle about the amount of
On Mar 11, 2010, at 6:00 PM, Andrew Dunstan wrote:
Tom Lane wrote:
I was looking at this recent nonrepeatable buildfarm failure:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecatdt=2010-03-11%2021:45:10
which has several instances of the known pgstat wait timeout problem
I wrote:
Anyway it's only a guess. It could well be that that machine was simply
so heavily loaded that the stats collector couldn't respond fast enough.
I'm just wondering whether there's an unrecognized bug lurking here.
Still meditating on this ... and it strikes me that the pgstat.c code
Tom Lane wrote:
I wrote:
Anyway it's only a guess. It could well be that that machine was simply
so heavily loaded that the stats collector couldn't respond fast enough.
I'm just wondering whether there's an unrecognized bug lurking here.
Still meditating on this ... and it strikes me
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
Still meditating on this ... and it strikes me that the pgstat.c code
is really uncommunicative about problems. In particular,
pgstat_read_statsfile_timestamp and pgstat_read_statsfile don't complain
at all about being unable
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
I also think the autovacuum worker minimum timestamp may be playing
games with the retry logic too. Maybe a worker is requesting a new file
continuously because pgstat is not able to provide one before the
deadline is
Alvaro Herrera alvhe...@commandprompt.com writes:
Since the warning comes from the launcher and not the worker, I wonder
if this is a red herring.
It's all speculation at the moment. So far there's not really enough
evidence to refute the idea that the system was just under heavy load
at that
Tom Lane wrote:
I was looking at this recent nonrepeatable buildfarm failure:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecatdt=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
14 matches
Mail list logo
