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

Re: Visibility regression test

From: John Gray <jgray(at)azuli(dot)co(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Manfred Koizar <mkoi-pg(at)aon(dot)at>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Visibility regression test
Date: 2002-08-29 15:51:10
Message-ID: 1030636273.2037.13.camel@adzuki (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Thu, 2002-08-29 at 16:37, Tom Lane wrote:
> Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> > On Thu, 29 Aug 2002 10:30:59 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> > wrote:
> >> Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> > A new regression test trying to detect runaway INSERTs/UPDATEs.
> >> 
> >> Why?
> > Because we do not want to run a database that gets hung in an endless
> > loop on INSERT or UPDATE.  Better we find such bugs during regression
> > testing.
> If there is such a problem it will surely be found by the other
> regression tests.  I don't see a need to insert a test that has an
> acknowledged system dependency in order to detect this.

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.

How about the following as a possible approach:

We produce an application which opens two (or more?) database
connections and feeds appropriate SQL to them. ISTM that this need not
be a very complicated application. It takes one input file whose lines
begin with (say) '-' for a comment, '1' for connection 1, '2' for
connection 2 etc. followed by the SQL statement to send. (This is all
very sketchy, of course -there might be better ways to format it). The
output from each backend is sent to a separate file for comparison
against the expected results.

Does this sound feasible or useful? It would offer a means to test tuple
visibility, concurrent updates and deadlock detection in a controlled
way without too much difficulty.


John Gray	
Azuli IT	

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2002-08-29 16:02:59
Subject: Re: Proposed patch for qual pushdown into UNION/INTERSECT
Previous:From: Stephan SzaboDate: 2002-08-29 15:46:00
Subject: Re: Proposed patch for qual pushdown into UNION/INTERSECT

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