RE: Proposal: Conflict log history table for Logical Replication - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Proposal: Conflict log history table for Logical Replication
Date
Msg-id OS9PR01MB12149D35EA9BE9E588806F5B2F5A62@OS9PR01MB12149.jpnprd01.prod.outlook.com
Whole thread
In response to Re: Proposal: Conflict log history table for Logical Replication  (shveta malik <shveta.malik@gmail.com>)
List pgsql-hackers
> I found two race conditions wrong remote_xid can be reported for streaming=on
> case.

I also found similar issue that wrong remote_commit_ts can be reported for streaming=on
and PREPARED transaction.

1. insert initial tuples on publisher:
2. Delete a tuple on subscriber:
3. Start a large transaction (T1) to stream the change and PREPARE:
publisher=# BEGIN;
SELECT txid_current();
UPDATE foo
   SET b = 'T1-' || repeat('x', 20000000)
 WHERE a = 1;
BEGIN
 txid_current 
--------------
          697
(1 row)
publisher=*# PREPARE TRANSACTION 'test';

4. Do COMMIT PREPARED. CLT can be updated here.
5. Check the conflict log table on subscriber. remote_commit_ts should be appeared
  but NULL can be reported. If the apply worker had applied other transactions before,
  the timetstamp could be reported.

subscriber=# SELECT remote_xid, remote_commit_ts FROM pg_conflict.pg_conflict_log_16392;
 remote_xid | remote_commit_ts 
------------+------------------
        697 | 
(1 row)

IIUC it's because remote_commit_ts is not updated in apply_handle_stream_prepare().
We should follow what apply_handle_stream_commit() does.

Best regards,
Hayato Kuroda
FUJITSU LIMITED


pgsql-hackers by date:

Previous
From: "pgsql-hackers"
Date:
Subject: Re: Unsafe qual pushdown through DISTINCT with simple CASE expressions
Next
From: John Naylor
Date:
Subject: Re: Optimize UUID parse using SIMD