After some debugging I am quite sure it is a bug in the version of MariaDB.
A workaround to prevent this error is to paste the following code into the velocity macro the page WikiManager.WikisLiveTableResultsMacros:
#macro(gridresultwithfilter_buildJSON $className $collist $filterfrom $filterwhere $filterParams $map)
#gridresultwithfilter_buildQuery($className $collist $filterfrom $filterwhere $filterParams)
#set($discard = $map.put('reqNo', $mathtool.toInteger($request.reqNo)))
#gridresult_buildRowsJSON($map)
#end
This helps because it overwrites a macro from the livetable that also tries to fetch tags for the results (I did not check why), and the error comes out of the tag plugin:
Caused by: com.xpn.xwiki.XWikiException: Error number 0 in 3: Failed to get tag count for query [select elements(prop.list) from XWikiDocument as doc, BaseObject as tagobject, DBStringListProperty as prop, BaseObject as obj , LargeStringProperty prop_dtable where tagobject.name=doc.fullName and tagobject.className='XWiki.TagClass' and tagobject.id=prop.id.id and prop.id.name='tags' and doc.translation=0 and obj.name=doc.fullName and obj.className = ? and doc.fullName <> ? and obj.id=prop_dtable.id.id and prop_dtable.name = ? and doc.name IN ('XWikiServerXwiki','XWikiServerTestwiki','XWikiServerMargarettingtye')], with parameters [[XWiki.XWikiServerClass, XWiki.XWikiServerClassTemplate, description]]
at com.xpn.xwiki.plugin.tag.TagQueryUtils.getTagCountForQuery(TagQueryUtils.java:133)
at com.xpn.xwiki.plugin.tag.TagPlugin.getTagCountForQuery(TagPlugin.java:293)
at com.xpn.xwiki.plugin.tag.TagPluginApi.getTagCountForQuery(TagPluginApi.java:157)
at sun.reflect.GeneratedMethodAccessor625.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395)
at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384)
at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173)
... 206 more
Of course this is not a fix, and the problem should reappear in other livetables. (The document index seems to work just fine, however.)
One can reproduce the issue with a minimal SQL for the XWiki DB like:
SELECT xwikilistitems.XWL_NAME
FROM
xwikilists,
xwikilistitems
cross join xwikiobjects
cross join xwikilargestrings
WHERE
xwikilists.XWL_ID=xwikilistitems.XWL_ID
LIMIT 1
which makes no sense whatever but also shows the error message Unknown column 'xwikilists.XWL_ID' in 'where clause'
Another reason why I think it is a MariaDB bug is that the following query:
SELECT a.id FROM a, b cross join c cross join d;
with some dummy tables containing just an id column also triggers an error with mariaDB 10.1.41, but not with 10.1.38
Edit: I send a bug report to the MariaDB issue tracker and downgraded my MariaDB server with:
# apt-get install mariadb-server-10.1=10.1.37-0+deb9u1 mariadb-server-core-10.1=10.1.37-0+deb9u1
# apt-mark hold mariadb-server-10.1 mariadb-server-core-10.1 mariadb-server
I guess I will keep it that way instead of trying to work around the problem on the XWiki side, and I hope the issue will be fixed soon.
Edit 2: the MariaDB developers responded that my bug report was a duplicate and that the issue has been fixed in 10.1.42 (and all other affected versions). For the Debian distribution we probably have to wait until the next security update (at least for Debian9 aka stretch).
