Hello
I see two more issue in v9.
1: there's a window for a permanent statistics leak when a tablespace
is dropped.
Maybe entries should be created eagerly during create tablespace and
only looked up with create = false for aggregation?
setup { SET allow_in_place_tablespaces = on; }
setup { CREATE TABLESPACE ts_res LOCATION ''; }
setup
{
CREATE TABLE t_res (a int) TABLESPACE ts_res;
INSERT INTO t_res SELECT generate_series(1, 100);
CREATE TABLE ts_oid AS SELECT oid FROM pg_tablespace WHERE spcname =
'ts_res';
}
# Session teardowns run before this, so t_res is already gone.
teardown { DROP TABLESPACE IF EXISTS ts_res; }
session s1
setup
{
SET debug_parallel_query = off;
SELECT count(*) FROM t_res;
SELECT pg_stat_force_next_flush();
}
step s1_read { SELECT count(*) FROM t_res; }
step s1_flush { SELECT pg_stat_force_next_flush(); }
session s2
step s2_drop_table { DROP TABLE t_res; }
step s2_drop_ts { DROP TABLESPACE ts_res; }
step s2_check
{
SELECT EXISTS (SELECT FROM pg_tablespace t WHERE t.oid = o.oid) AS
in_catalog,
pg_stat_have_stats('tablespace', 0, o.oid::int8) AS
have_stats
FROM ts_oid o;
}
teardown
{
DROP TABLE IF EXISTS t_res;
DROP TABLE ts_oid;
}
# s1's pending counts flush after the drop
permutation s2_check s1_read s2_drop_table s2_drop_ts s2_check s1_flush s2_check
2: Are you sure the transaction move behavior is correct? The test
case even documents it:
+-- A relation moved to another tablespace must be credited to the new one in
+-- pg_stat_tablespace. pgstat_info is preserved across a relcache rebuild, so
+-- doing this while the relation is already in use exercises
+-- pgstat_relation_update_tablespace().
+CREATE TABLE tablespace_stats_move (a int);
+INSERT INTO tablespace_stats_move SELECT generate_series(1, 10);
+SELECT pg_stat_force_next_flush();
+SELECT tup_inserted AS stats_move_before FROM pg_stat_tablespace
+ WHERE tablespace_name = 'regress_tblspace' \gset
+
+BEGIN;
+SELECT count(*) > 0 FROM tablespace_stats_move;
+ALTER TABLE tablespace_stats_move SET TABLESPACE regress_tblspace;
+INSERT INTO tablespace_stats_move SELECT generate_series(1, 10);
+COMMIT;
+SELECT pg_stat_force_next_flush();
But looking at this test case, the table was read in the old
tablespace, not in the new, so attributing this to the new tablespace
doesn't seem right to me?
