Date: 2017-08-22 14:42:40 +0200
From: Richard Hughes <<richard.monetdb>>
To: SQL devs <>
Version: 11.27.5 (Jul2017-SP1)

Last updated: 2017-10-26 14:01:34 +0200

Comment 25590

Date: 2017-08-22 14:42:40 +0200
From: Richard Hughes <<richard.monetdb>>

Build is Jul2017 a55ec984eb42

To reproduce:
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 161 |
+------+
1 tuple (11.032ms)
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 163 |
+------+
1 tuple (9.218ms)
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 165 |
+------+
1 tuple (9.192ms)
sql>select count() from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 167 |
+------+
1 tuple (9.083ms)
sql>select count(*) from sys.bbp() where kind='transient';
+------+
| L4 |
+======+
| 169 |
+------+
1 tuple (8.975ms)

Expected: that number should not be increasing

The issue can be reproduced with any query which is guaranteed to return one row, e.g. "select 1;". I used the example above because it both reproduces and demonstrates the issue in a single query.

Each run of the query leaks 1+<number_of_result_columns> BATs.

The issue appears to be in mvc_scalar_value_wrap(), which is calling mvc_result_table() and then discarding the result so it can never call res_tables_remove(res_tables_find()) on it. The equivalent code in mvc_row_result_wrap() (i.e. for multi-row results, which don't leak) is rather different so I'm not sure what's the neatest patch.

Comment 25591

Date: 2017-08-22 17:45:39 +0200
From: MonetDB Mercurial Repository <>

Changeset 2167d80ea078 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.

For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=2167d80ea078

Changeset description:

When creating BATs to wrap scalar results, unfix them.
This fixes bug #6395.

Comment 25593

Date: 2017-08-23 12:03:08 +0200
From: Richard Hughes <<richard.monetdb>>

Confirmed.

Sorry for the misleading commentary above - I did most of my debugging on Jun2016 then only tested its existence on Jul2017.

Comment 25595

Date: 2017-08-23 13:34:06 +0200
From: @sjoerdmullender

Your comments did help in locating the problem.
I'm glad the fix is confirmed.