Re: Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <mail(at)joeconway(dot)com>
Cc: <drkp(at)csail(dot)mit(dot)edu>,<fgp(at)phlo(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle
Date: 2010-07-19 03:06:15
Message-ID: 4C437AD70200002500033879@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway wrote:

> "make dcheck" is running now (although seems rather slow).

Yeah, most of those tests completely reset the environment for each
permutation. I thought about changing it to update back to the same
"visible" initial state each time, but it struck me that since this
would accumulate more and more dead tuples as the tests advanced, it
would exercise different code paths, so I've kinda got it in mind to
add the faster tests as *additional* tests rather than eliminating
the existing ones. I know they're way to slow to consider including
in the normal "make check" suite, but when (if?) we get a "test farm"
set up, this sort of thing seems like it would be in scope.

On the other hand, maybe we should have a "quick" set of dtester
tests and a more comprehensive one? I'm open to ideas.

-Kevin

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-07-19 05:02:08 Re: crash-recovery replay of CREATE TABLESPACE is broken in HEAD
Previous Message Robert Haas 2010-07-19 02:47:42 Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock