heterodb/pg-strom

gpu_cache有効化テーブルにALTER TABLEで列を追加後にUPDATEを実行するとunable to write out GpuCache Logが多発する

Closed this issue · 4 comments

ALTER TABLE cache_test_table ADD COLUMN k int2;
UPDATE cache_test_table SET k=a/2;

上記を実行すると以下のようなメッセージが多発します。

WARNING:  gpucache: rowid exceeds max_num_rows (10000), so it is now switched to 'corrupted' state
WARNING:  Bug? unable to write out GpuCache Log
WARNING:  Bug? unable to write out GpuCache Log
WARNING:  Bug? unable to write out GpuCache Log
WARNING:  Bug? unable to write out GpuCache Log
WARNING:  Bug? unable to write out GpuCache Log

全体クエリ:

SET pg_strom.regression_test_mode = on;
SET client_min_messages = error;
DROP SCHEMA IF EXISTS gpu_cache_temp_test CASCADE;
CREATE SCHEMA gpu_cache_temp_test;
RESET client_min_messages;
SET search_path = gpu_cache_temp_test,public;
---
--- Creating a table on GPU cache
---
CREATE TABLE cache_test_table (
  id   int,
  a    int1
);
---
--- GPU Cache configuration
---
CREATE TRIGGER row_sync_test AFTER INSERT OR UPDATE OR DELETE ON cache_test_table FOR ROW 
    EXECUTE FUNCTION pgstrom.gpucache_sync_trigger('gpu_device_id=0,max_num_rows=10000,redo_buffer_size=150m,gpu_sync_threshold=10m,gpu_sync_interval=4');
ALTER TABLE cache_test_table ENABLE ALWAYS TRIGGER row_sync_test;
-- Make GPU cache 
INSERT INTO cache_test_table(id) values (1);
-- Check gpucache_info table.
SELECT config_options FROM pgstrom.gpucache_info WHERE table_name='cache_test_table' AND database_name=current_database();

TRUNCATE TABLE cache_test_table;
-- Force to use GPU Cache
SET enable_seqscan=off;
---
--- INSERT 
---
EXPLAIN (costs off, verbose)
INSERT INTO cache_test_table(id) values (1);


INSERT INTO cache_test_table (
  SELECT x 
  ,pgstrom.random_int(1,-128,127)     -- a int1
  FROM generate_series(1,4000) x
);
VACUUM ANALYZE;

ALTER TABLE cache_test_table ADD COLUMN k int2;
UPDATE cache_test_table SET k=a/2;

これ、直接的な原因はBug? unable to write out GpuCache Logの直上のgpucache: rowid exceeds max_num_rows (10000), so it is now switched to 'corrupted' stateぽいですね。

max_num_rows=10000なので、それほど余裕はないっぽい気はします。

とはいえ、max_num_rowsを10倍にしても発生しますか。

明日調べてみます。

3cd806bb56d91802ca7a94ce983c68ff7c3fa27c で解決。

列定義の変更を伴うALTER TABLEを実行すると、GpuCacheが破棄されます。
それに続いてUPDATEを実行した場合、AFTER-ROWトリガによりInitial-Loadingが実行されますが、
その時、(1) 当該UPDATEコマンドにより挿入された newtuple をロードしてしまう (2) 当該UPDATEコマンドにより
削除された oldtuple をスキップしてしまうという問題がありました。

すると、Initial-Loadingの後にAFTER-ROWトリガを実行すると (1)のタプルを二重にロードしてしまう
(2)のタプルを二重に削除してしまうという問題があり、それ故に rowid の過剰消費と、それを起点とする
GpuCacheのcorruptedステートへの移行が発生したものと思われます。

解消確認できました。ありがとうございました。