(JP) tcacheによるキャッシュ構築中に共有メモリ不足エラーとなると、メモリ開放漏れが発生することがある

[taiki-k]

現時点の最新のソースで、psql上から大量のデータを持つテーブルの検索を行い、共有メモリ不足に陥ると、それまでに確保した領域が解放されない状況となりました。

explainでGpuScanとなることを確認した直後に、発生しているように見えます。

使用したテーブルは、 #4 で使用したものと同一のものです。

pgstrom_test=# \d oku_table
       Table "public.oku_table"
 Column |       Type       | Modifiers
--------+------------------+-----------
 id     | integer          |
 data   | double precision |

pgstrom_test=# explain select id from oku_table where data < 0.1;
INFO:  tc_scan->heapscan = 0x1fb87e0
                                   QUERY PLAN
---------------------------------------------------------------------------------
 Custom (GpuScan) on oku_table  (cost=10000.00..664461.62 rows=10142061 width=4)
   Host References: id
   Device References: data
   Device Filter: (data < 0.1::double precision)
 Planning time: 0.225 ms
(5 rows)

pgstrom_test=# select id from oku_table where data < 0.1;
INFO:  tc_scan->heapscan = 0x1fb5f90
INFO:  now building tcache...
ERROR:  out of shared memory
pgstrom_test=# select * from pgstrom_shmem_info();
 zone | size | active | free
------+------+--------+------
    0 | 8K   |      4 |    1
    0 | 16K  |      0 |    1
    0 | 32K  |      0 |    1
    0 | 64K  |      0 |    1
    0 | 128K |      0 |    1
    0 | 256K |      0 |    0
    0 | 512K |      0 |    1
    0 | 1M   |      0 |    0
    0 | 2M   |      0 |    1
    0 | 4M   |      0 |    1
    0 | 8M   |      0 |    1
    0 | 16M  |    119 |    0
    0 | 32M  |      0 |    0
    0 | 64M  |      0 |    0
    0 | 128M |      0 |    0
    0 | 256M |      0 |    0
    0 | 512M |      0 |    0
    0 | 1G   |      0 |    0
    0 | 2G   |      0 |    0
    0 | 4G   |      0 |    0
    0 | 8G   |      0 |    0
    0 | 16G  |      0 |    0
(22 rows)

[kaigai]

再現条件：

1. EXPLAIN で実行プランが GpuScan である事を確認。
2. 全件探索中に out of shared memory ⇒ エラー発生
3. tcache_column_store が解放されないまま残る。

仮説）
EXPLAIN時に tcache_head を掴むため、この時点で refcnt = 1
EXPLAIN終了時に creator が refcnt = 1 のまま放置するのは正しい動作。

次に GpuScan が tcache_head を掴んで、この時点で refcnt = 2
実行中に out of shared memory エラーの発生で、エラー回復ルーチンが
refcnt 2=>1 にデクリメント。しかし、refcnt == 0 ではないので、獲得した
メモリを開放するという動作にはならない。

[kaigai]

対策）　「俺がこのキャッシュをビルド中」というフラグと共にオブジェクトをトラッキングする。

ビルド中の人がエラーで中断の場合、構築半ばの木を開放する。

[kaigai]

上記の方針で修正しました。

（*） Columnar-Store 一枚分だけメモリが残っているのは正しい動作です。

[kaigai@magro pg_strom]$ psql postgres
psql (9.4devel)
Type "help" for help.

postgres=# explain select count(*) from t1 where sqrt((x-20.0)^2 + (y-20.0)^2) < 10;

QUERY PLAN

Aggregate (cost=344643.21..344643.22 rows=1 width=0)
-> Custom (GpuScan) on t1 (cost=10000.00..332862.87 rows=4712136 width=0)
Host References:
Device References: x, y
Device Filter: (sqrt((((x - 20::double precision) ^ 2::double precision) + ((y - 20::double precision) ^ 2::double precision))) < 10::double precision)
Planning time: 0.407 ms
(6 rows)

postgres=# select * from pgstrom_tcache_info();
datoid | reloid | cached | refcnt | state | lwlock
--------+--------+--------+--------+-----------+----------
13046 | 16419 | 1 2 | 1 | not built | unlocked
(1 row)

postgres=# select count() from t1 where sqrt((x-20.0)^2 + (y-20.0)^2) < 10;
INFO: now building tcache...
ERROR: out of shared memory
STATEMENT: select count() from t1 where sqrt((x-20.0)^2 + (y-20.0)^2) < 10;
ERROR: out of shared memory
postgres=# select * from pgstrom_tcache_info();
datoid | reloid | cached | refcnt | state | lwlock
--------+--------+--------+--------+-----------+----------
13046 | 16419 | 1 2 | 1 | not built | unlocked
(1 row)

postgres=# select * from pgstrom_shmem_active_info();
zone | address | size | owner | location | broken | overrun
------+-----------------+----------+-------+---------------+--------+---------
0 | 139987793297432 | 12124264 | 24306 | tcache.c:374 | f | f
0 | 139988294909976 | 8080 | 24306 | mqueue.c:82 | f | f
0 | 139988294975512 | 8164 | 24306 | tcache.c:2528 | f | f
(3 rows)

[taiki-k]

最新版ソースで再現確認を行い、再現しませんでした。
修正されたものと判断します。