Hi Dilip,
I found two race conditions wrong remote_xid can be reported for streaming=on
case.
Assuming that there is a table foo (a int PRIMARY KEY, b text).
1. insert initial tuples on publisher:
publisher=# INSERT INTO foo VALUES (1, 'init'), (2, 'init');
2. Delete a tuple on subscriber:
subscriber=# DELETE FROM foo WHERE a = 1;
3. Start a large transaction (T1) to stream the change:
publisher=# BEGIN;
SELECT txid_current();
UPDATE foo
SET b = 'T1-' || repeat('x', 20000000)
WHERE a = 1;
BEGIN
txid_current
--------------
697
(1 row)
4. Start another transaction (T2) and commit immediately
publisher=# BEGIN;
SELECT txid_current();
UPDATE foo SET b = 'T2' WHERE a = 2;
COMMIT;
BEGIN
txid_current
--------------
698
(1 row)
UPDATE 1
COMMIT
5. Commit the T1. It causes the update_missing conflict.
6. Check the conflict log table on subscriber. The remote_xid should be 697,
but 698 can be reported.
subscriber=# SELECT remote_xid FROM pg_conflict.pg_conflict_log_16392;
remote_xid
------------
698
(1 row)
IIUC, it's because apply_spooled_messages() does not restore the remote_xid
before applying changes unlike remote_final_lsn. Can we fix here or should be
done separately?
Best regards,
Hayato Kuroda
FUJITSU LIMITED
