Skip site navigation (1) Skip section navigation (2)

Re: Isolation tests still falling over routinely

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <alvherre(at)commandprompt(dot)com>,<tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Isolation tests still falling over routinely
Date: 2011-09-21 01:51:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane  wrote:
> The buildfarm is still showing isolation test failures more days
> than not, eg
> and I've personally seen such failures when testing with
> CLOBBER_CACHE_ALWAYS. Could we please fix those tests to not have
> such fragile timing assumptions?
I went back over two months, and only found one failure related to an
SSI test, and that was because the machine ran out of disk space. 
There should never be any timing-related failures on the SSI tests,
as there is no blocking or deadlocking.
If you have seen any failures on isolation tests other than the fk-*
tests, I'd be very interested in details.
The rest are not related to SSI but test deadlock conditions related
to foreign keys.  I didn't have anything to do with these but to
provide alternate result files for REPEATABLE READ and SERIALIZABLE
isolation levels.  (I test the installcheck-world target and the
isolation tests in those modes frequently, and the fk-deadlock tests
were failing every time at those levels.)
If I remember right, Alvaro chose these timings to balance run time
against chance of failure.  Unless we want to remove these deadlock
handling tests or ignore failures (which both seem like bad ideas to
me), I think we need to bump the long timings by an order of
magnitude and just concede that those tests run for a while.


pgsql-hackers by date

Next:From: Dan McGeeDate: 2011-09-21 01:54:20
Subject: [PATCH] POC: inline int4 comparison in tuplesort
Previous:From: Alvaro HerreraDate: 2011-09-21 01:00:47
Subject: Re: WIP: Collecting statistics on CSV file data

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group