[Monetdb-developers] stable xq testweb
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. 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 No to the oher differences (ignoring xrpc and W3c/qn/ns which AFAIK has always failed).. The below use recursive functions for which we maybe could add 'declare option pf:recursion-depth "<number>";?? 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
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@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 |
participants (2)
-
Peter Boncz
-
Stefan Manegold