| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Better way of dealing with pgstat wait timeout during buildfarm runs? |
| Date: | 2014-12-25 21:40:48 |
| Message-ID: | 30127.1419543648@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
> The strange thing is that the split happened ~2 years ago, which is
> inconsistent with the sudden increase of this kind of issues. So maybe
> something changed on that particular animal (a failing SD card causing
> I/O stalls, perhaps)?
I think that hamster has basically got a tin can and string for an I/O
subsystem. It's not real clear to me whether there's actually been an
increase in "wait timeout" failures recently; somebody would have to
go through and count them before I'd have much faith in that thesis.
However, I notice that at least the last few occurrences on "hamster"
all seem to have been in this parallel block:
test: brin gin gist spgist privileges security_label collate matview lock replica_identity rowsecurity object_address
which as recently as 9.4 contained just these tests:
test: privileges security_label collate matview lock replica_identity
I'm fairly sure that the index-related tests in this batch are I/O
intensive, and since they were not there at all six months ago, it's not
hard to believe that this block of tests has far greater I/O demands than
used to exist. Draw your own conclusions ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2014-12-25 21:52:42 | Re: Better way of dealing with pgstat wait timeout during buildfarm runs? |
| Previous Message | Tomas Vondra | 2014-12-25 21:28:26 | Re: Better way of dealing with pgstat wait timeout during buildfarm runs? |