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

Re: Visibility regression test

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Gray <jgray(at)azuli(dot)co(dot)uk>
Cc: Manfred Koizar <mkoi-pg(at)aon(dot)at>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Visibility regression test
Date: 2002-08-29 16:11:19
Message-ID: 8733.1030637479@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
John Gray <jgray(at)azuli(dot)co(dot)uk> writes:
> I agree with this, but I think an earlier suggestion of Manfred's,
> (namely tests that explicitly check concurrency issues) might be useful
> to verify the integrity of MVCC.

Indeed, we could use some sort of parallel-testing harness to allow
fine-grained verification of concurrent behavior.  This has been
discussed several times, but no one's stepped up to the plate.

Your sketch misses an important point: we want to know not only what
each backend does, but when it does it.  (For example, we'd want the
test harness to be able to check that LOCK actually prevents another
backend from making progress.)  A brute-force way to do that would be
to delay for some amount of time between issuing commands, so that we
can be sure the backends have reached a quiescent state.  Then, logging
all the commands and responses serially into a single file would provide
some idea of causal order.  It could still be tricky though, eg if an
unlock releases two other backends then their results could arrive in
either order.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2002-08-29 16:14:24
Subject: Re: [HACKERS] Proposed GUC Variable
Previous:From: Robert TreatDate: 2002-08-29 16:09:58
Subject: Re: [HACKERS] Proposed GUC Variable

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