Re: Visibility regression test
От | John Gray |
---|---|
Тема | Re: Visibility regression test |
Дата | |
Msg-id | 1030636273.2037.13.camel@adzuki обсуждение исходный текст |
Ответ на | Re: Visibility regression test (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Visibility regression test
|
Список | pgsql-patches |
On Thu, 2002-08-29 at 16:37, Tom Lane wrote: > Manfred Koizar <mkoi-pg@aon.at> writes: > > On Thu, 29 Aug 2002 10:30:59 -0400, Tom Lane <tgl@sss.pgh.pa.us> > > wrote: > >> Manfred Koizar <mkoi-pg@aon.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. Regards John -- John Gray Azuli IT www.azuli.co.uk
В списке pgsql-patches по дате отправления: