Fix txid test case
authorPavan Deolasee <[email protected]>
Tue, 8 Aug 2017 05:35:15 +0000 (11:05 +0530)
committerPavan Deolasee <[email protected]>
Tue, 8 Aug 2017 05:35:15 +0000 (11:05 +0530)
- Accept expected output difference because FirstNormalTransactionId's status
  is reported as 'committed' in XL. This happens because the oldestXmin is
  advanced lazily in XL and hence clog truncation happens lazily too.

- Accept error message because of lack of SAVEPOINT support. But we added a new
  test case to test the functionality

src/test/regress/expected/txid.out
src/test/regress/sql/txid.sql

index abd20bfed6f330997b47e5d3af70a2fdd9471031..d98eecd5e28da7e48fbd3acf463f205e29afa858 100644 (file)
@@ -293,10 +293,14 @@ SELECT txid_status(2); -- FrozenTransactionId is always committed
  committed
 (1 row)
 
-SELECT txid_status(3); -- in regress testing FirstNormalTransactionId will always be behind oldestXmin
+-- in regress testing FirstNormalTransactionId will always be behind oldestXmin
+-- XXX in XL, the oldestXmin is advanced lazily and depends on the global
+-- state. So the clog for FirstNormalTransactionId may very well exist and
+-- txid_status gives us a correct answer
+SELECT txid_status(3);
  txid_status 
 -------------
+ committed
 (1 row)
 
 COMMIT;
@@ -315,10 +319,10 @@ EXCEPTION
 END;
 $$;
 SELECT test_future_xid_status(:inprogress + 10000);
-NOTICE:  Got expected error for xid in the future
- test_future_xid_status 
-------------------------
-(1 row)
-
+ERROR:  Internal subtransactions not supported in Postgres-XL
+CONTEXT:  PL/pgSQL function test_future_xid_status(bigint) line 2 during statement block entry
 ROLLBACK;
+-- add a new test case for coverage in XL. Use some very large value for
+-- consistent output
+SELECT txid_status(10000000);
+ERROR:  transaction ID 10000000 is in the future
index 7a6be23628d1e7f8665c98a28ca8c44ef2dc5cbd..c5ecaeb663888a1dd3214d8fea40e3a2c4a5f6bb 100644 (file)
@@ -77,7 +77,11 @@ SELECT txid_status(:rolledback) AS rolledback;
 SELECT txid_status(:inprogress) AS inprogress;
 SELECT txid_status(1); -- BootstrapTransactionId is always committed
 SELECT txid_status(2); -- FrozenTransactionId is always committed
-SELECT txid_status(3); -- in regress testing FirstNormalTransactionId will always be behind oldestXmin
+-- in regress testing FirstNormalTransactionId will always be behind oldestXmin
+-- XXX in XL, the oldestXmin is advanced lazily and depends on the global
+-- state. So the clog for FirstNormalTransactionId may very well exist and
+-- txid_status gives us a correct answer
+SELECT txid_status(3);
 
 COMMIT;
 
@@ -97,3 +101,7 @@ END;
 $$;
 SELECT test_future_xid_status(:inprogress + 10000);
 ROLLBACK;
+
+-- add a new test case for coverage in XL. Use some very large value for
+-- consistent output
+SELECT txid_status(10000000);