[Monetdb-developers] stable xq testweb

Stefan Manegold Stefan.Manegold at cwi.nl
Tue Feb 10 00:01:35 CET 2009


Hi Peter,

thanks for checking and commenting!

On Sun, Feb 08, 2009 at 12:05:17PM +0100, Peter Boncz wrote:
> Hi,
> 
> (the below analyis of the Stable XQ testweb is not an implicit request for
> anybody to do something, I just share it here so you will not do double
> work)
> 
> Recently I checked in some fixes.
> - Because I have the suspicion that certain scripts at NFI may still use
> hard commits, I redefined the commit() in module pathfinder to giving an
> error.
> - I also added pflock_trycommit(), as part of the change (hack?) to ensure
> that checkpoint flushes occur only on an idle system.
> 
> This led me to expect the Stable testweb in detail today. 
> 
> My new commit() error policy causes the following tests to display different
> output:
> 
> benchmarks/XPath*/import_doc
> benchmarks/XMark*/import_doc
> benchmarks/Music*/import_doc
> tests/BugsViaSourgeforce/ ID.1078462_import
> tests/Standoff/video/import_doc
> tests/W3C_use_cases/XQUF/AddressBook/check_docs
> tests/i18n/import_doc
> tests/WebSite/voc
> 
> I think what we could do is to substitute the commit() by a pf_logflush(0LL)
> , although simply omitting the "commit();"should also work.

I did the latter --- the respective tests seem to work fine without commit();

> The pflock_trycommit() new command obviously alsoshows up in some tests.
> However, I also saw time-, standoff- and pf-tjah related output that
> probably can be approved:
> 
> modules/pftijah/procs
> runtime/sigs
> runtime/procs

approved.

> No to the oher differences (ignoring xrpc and W3c/qn/ns which AFAIK has
> always failed)..

I conditionally disabled the XRpc tests in benchmarks/XMark/XRpc/,
tests/XRpc/ & runtime/xrpc/admin/ (for now in the Feb2009 release branch,
only)

There might be some more individual tests the use XRpc ...

> The below use recursive functions for which we maybe could add 'declare
> option pf:recursion-depth "<number>";??

I conditionally disabled all tests that use/require recursive functions in
case the algebra back-end is used (for now in the Feb2009 release branch,
only)

> tests/BugTracker/Alignment_error.SF-1886994
> tests/BugTracker/recursive_function.SF-1835745
> tests/BugTracker/pf-O0_produces_wrong_MIL.SF-1771532
> tests/BugTracker/posjoin_null_BAT_2nd_run.SF-1678948
> tests/BugTracker/error-KO2.SF-1562868
> recursion_type_error.SF-1579524
> tests/BugsViaSourgeforce/ID.1652527
> tests/W3C_use_cases/XQ/PARTS/Q1[x]
> tests/W3C_use_cases/XQ/TREE/Q[1,6]
> tests/W3C_use_cases/XQUF/Parts/q3b[12]
> tests/WebSite/books2,3
> tests/XQuery/fun1,4
>
> which leaves us with 6 the following suspect regressions:
> 
> tests/BugTracker/replace-corrupts.SF-1758902
> tests/BugTracker/1637867.xq 
> tests/BugTracker/1pagedoc.SF-2141012
> tests/BugTracker/Zombie_document.SF-2009556
> tests/W3C_use_cases/XQUF/AddressBook/check_docs
> tests/Update/insert_test_order_seq

The cleaned-up test web tomorrow will give a clearer view ...

Stefan

-- 
| Dr. Stefan Manegold | mailto:Stefan.Manegold at cwi.nl |
| CWI,  P.O.Box 94079 | http://www.cwi.nl/~manegold/  |
| 1090 GB Amsterdam   | Tel.: +31 (20) 592-4212       |
| The Netherlands     | Fax : +31 (20) 592-4312       |




More information about the developers-list mailing list