mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-12 18:57:52 +02:00
895a94de6d
but no database changes have been made since the last CommandCounterIncrement. This should result in a significant improvement in the number of "commands" that can typically be performed within a transaction before hitting the 2^32 CommandId size limit. In particular this buys back (and more) the possible adverse consequences of my previous patch to fix plan caching behavior. The implementation requires tracking whether the current CommandCounter value has been "used" to mark any tuples. CommandCounter values stored into snapshots are presumed not to be used for this purpose. This requires some small executor changes, since the executor used to conflate the curcid of the snapshot it was using with the command ID to mark output tuples with. Separating these concepts allows some small simplifications in executor APIs. Something for the TODO list: look into having CommandCounterIncrement not do AcceptInvalidationMessages. It seems fairly bogus to be doing it there, but exactly where to do it instead isn't clear, and I'm disinclined to mess with asynchronous behavior during late beta.
94 lines
2.2 KiB
PL/PgSQL
94 lines
2.2 KiB
PL/PgSQL
--
|
|
-- Tests for some likely failure cases with combo cmin/cmax mechanism
|
|
--
|
|
CREATE TEMP TABLE combocidtest (foobar int);
|
|
|
|
BEGIN;
|
|
|
|
-- a few dummy ops to push up the CommandId counter
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
|
|
INSERT INTO combocidtest VALUES (1);
|
|
INSERT INTO combocidtest VALUES (2);
|
|
|
|
SELECT ctid,cmin,* FROM combocidtest;
|
|
|
|
SAVEPOINT s1;
|
|
|
|
UPDATE combocidtest SET foobar = foobar + 10;
|
|
|
|
-- here we should see only updated tuples
|
|
SELECT ctid,cmin,* FROM combocidtest;
|
|
|
|
ROLLBACK TO s1;
|
|
|
|
-- now we should see old tuples, but with combo CIDs starting at 0
|
|
SELECT ctid,cmin,* FROM combocidtest;
|
|
|
|
COMMIT;
|
|
|
|
-- combo data is not there anymore, but should still see tuples
|
|
SELECT ctid,cmin,* FROM combocidtest;
|
|
|
|
-- Test combo cids with portals
|
|
BEGIN;
|
|
|
|
INSERT INTO combocidtest VALUES (333);
|
|
|
|
DECLARE c CURSOR FOR SELECT ctid,cmin,* FROM combocidtest;
|
|
|
|
DELETE FROM combocidtest;
|
|
|
|
FETCH ALL FROM c;
|
|
|
|
ROLLBACK;
|
|
|
|
SELECT ctid,cmin,* FROM combocidtest;
|
|
|
|
-- check behavior with locked tuples
|
|
BEGIN;
|
|
|
|
-- a few dummy ops to push up the CommandId counter
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
INSERT INTO combocidtest SELECT 1 LIMIT 0;
|
|
|
|
INSERT INTO combocidtest VALUES (444);
|
|
|
|
SELECT ctid,cmin,* FROM combocidtest;
|
|
|
|
SAVEPOINT s1;
|
|
|
|
-- this doesn't affect cmin
|
|
SELECT ctid,cmin,* FROM combocidtest FOR UPDATE;
|
|
SELECT ctid,cmin,* FROM combocidtest;
|
|
|
|
-- but this does
|
|
UPDATE combocidtest SET foobar = foobar + 10;
|
|
|
|
SELECT ctid,cmin,* FROM combocidtest;
|
|
|
|
ROLLBACK TO s1;
|
|
|
|
SELECT ctid,cmin,* FROM combocidtest;
|
|
|
|
COMMIT;
|
|
|
|
SELECT ctid,cmin,* FROM combocidtest;
|