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
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? |