Re: Better way of dealing with pgstat wait timeout during buildfarm runs?

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
Date: 2014-12-26 02:26:24
Message-ID: CAB7nPqTQMRA8A8PJxDbnR4ditLtnkGfJrrQzvhcPAfdapkR7fg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 26, 2014 at 6:28 AM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
> On 25.12.2014 21:14, Andres Freund wrote:
>> On 2014-12-25 14:36:42 -0500, Tom Lane wrote:
>>
>> My guess is that a checkpoint happened at that time. Maybe it'd be a
>> good idea to make pg_regress start postgres with log_checkpoints
>> enabled? My guess is that we'd find horrendous 'sync' times.
>>
>> Michael: Could you perhaps turn log_checkpoints on in the config?
>
> Logging timestamps (using log_line_prefux) would be also helpful.
Done. If have been wondering about those failures as well but didn't
get the time to look around. FYI, hamster is running with a 8GB class
10 SD card able to do 40M/s in read, card that I changed 2 weeks ago
btw, the former 4GB card beginning to show I/O errors, RIP to it. So
this is what is triggering the wait timeouts more frequently... But I
have no real explanation why REL9_4_STABLE shows no signs of failures.

For the time being, what about putting pg_stats_tmp into a ram disk to
leverage the I/O? Whatever what we come up with, I imagine that I/O
will still be tight on hamster.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-12-26 03:18:54 Re: Some other odd buildfarm failures
Previous Message Tomas Vondra 2014-12-26 02:14:01 Re: Better way of dealing with pgstat wait timeout during buildfarm runs?