Re: Better way of dealing with pgstat wait timeout during buildfarm runs?
От | Tom Lane |
---|---|
Тема | Re: Better way of dealing with pgstat wait timeout during buildfarm runs? |
Дата | |
Msg-id | 30127.1419543648@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Better way of dealing with pgstat wait timeout during buildfarm runs? (Tomas Vondra <tv@fuzzy.cz>) |
Ответы |
Re: Better way of dealing with pgstat wait timeout during
buildfarm runs?
|
Список | pgsql-hackers |
Tomas Vondra <tv@fuzzy.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
В списке pgsql-hackers по дате отправления: