RE: Proposal: Conflict log history table for Logical Replication

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