src/test/modules/injection_points/specs/repack.spec - master - githubmirror/postgres

src/test/modules/injection_points/specs/repack.spec
143 строки4 KB
Álvaro Herrera
Fix REPACK CONCURRENTLY for stored generated columns
03 июл 2026, 13:22
03 июл 2026, 13:223be8234
# REPACK (CONCURRENTLY) ... USING INDEX ...;
setup
{
	CREATE EXTENSION injection_points;

	CREATE TABLE repack_test(i int PRIMARY KEY, j int,
				 k int GENERATED ALWAYS AS (j * 2) STORED);
	INSERT INTO repack_test(i, j) VALUES (1, 1), (2, 2), (3, 3), (4, 4);

	CREATE TABLE relfilenodes(node oid);

	CREATE TABLE data_s1(i int, j int);
	CREATE TABLE data_s2(i int, j int);
}

teardown
{
	DROP TABLE repack_test;
	DROP EXTENSION injection_points;

	DROP TABLE relfilenodes;
	DROP TABLE data_s1;
	DROP TABLE data_s2;
}

session s1
setup
{
	SELECT injection_points_set_local();
	SELECT injection_points_attach('repack-concurrently-before-lock', 'wait');
}
# Perform the initial load and wait for s2 to do some data changes.
step wait_before_lock
{
	REPACK (CONCURRENTLY) repack_test USING INDEX repack_test_pkey;
}
# Check the table from the perspective of s1.
#
# Besides the contents, we also check that relfilenode has changed.

# Have each session write the contents into a table and use FULL JOIN to check
# if the outputs are identical.
step check1
{
	INSERT INTO relfilenodes(node)
	SELECT relfilenode FROM pg_class WHERE relname='repack_test';

	SELECT count(DISTINCT node) FROM relfilenodes;

	SELECT i, j FROM repack_test ORDER BY i, j;

	INSERT INTO data_s1(i, j)
	SELECT i, j FROM repack_test;

	SELECT count(*)
	FROM data_s1 d1 FULL JOIN data_s2 d2 USING (i, j)
	WHERE d1.i ISNULL OR d2.i ISNULL;
}
teardown
{
	SELECT injection_points_detach('repack-concurrently-before-lock');
}

session s2
# Change the existing data. UPDATE changes both key and non-key columns. Also
# update one row twice to test whether tuple version generated by this session
# can be found.
step change_existing
{
	UPDATE repack_test SET i=10 where i=1;
	UPDATE repack_test SET j=20 where i=2;
	UPDATE repack_test SET i=30 where i=3;
	UPDATE repack_test SET i=40 where i=30;
	DELETE FROM repack_test WHERE i=4;
}
# Insert new rows and UPDATE / DELETE some of them. Again, update both key and
# non-key column.
step change_new
{
	INSERT INTO repack_test(i, j) VALUES (5, 5), (6, 6), (7, 7), (8, 8);
	UPDATE repack_test SET i=50 where i=5;
	UPDATE repack_test SET j=60 where i=6;
	DELETE FROM repack_test WHERE i=7;
}

# When applying concurrent data changes, we should see the effects of an
# in-progress subtransaction.
#
# XXX Not sure this test is useful now - it was designed for the patch that
# preserves tuple visibility and which therefore modifies
# TransactionIdIsCurrentTransactionId().
step change_subxact1
{
	BEGIN;
	INSERT INTO repack_test(i, j) VALUES (100, 100);
	SAVEPOINT s1;
	UPDATE repack_test SET i=101 where i=100;
	SAVEPOINT s2;
	UPDATE repack_test SET i=102 where i=101;
	COMMIT;
}

# When applying concurrent data changes, we should not see the effects of a
# rolled back subtransaction.
#
# XXX Is this test useful? See above.
step change_subxact2
{
	BEGIN;
	SAVEPOINT s1;
	INSERT INTO repack_test(i, j) VALUES (110, 110);
	ROLLBACK TO SAVEPOINT s1;
	INSERT INTO repack_test(i, j) VALUES (110, 111);
	COMMIT;
}

# Check the table from the perspective of s2.
step check2
{
	INSERT INTO relfilenodes(node)
	SELECT relfilenode FROM pg_class WHERE relname='repack_test';

	SELECT i, j FROM repack_test ORDER BY i, j;

	INSERT INTO data_s2(i, j)
	SELECT i, j FROM repack_test;
}
step wakeup_before_lock
{
	SELECT injection_points_wakeup('repack-concurrently-before-lock');
}

# Test if data changes introduced while one session is performing REPACK
# CONCURRENTLY find their way into the table.
permutation
	wait_before_lock
	change_existing
	change_new
	change_subxact1
	change_subxact2
	check2
	wakeup_before_lock
	check1