Re: Proposal: Conflict log history table for Logical Replication

Hi,

On Wed, Nov 4, 2026 at 03:08 PM Peter Smith wrote:
>
> I think the GUC timezone is yet another setting that can affect how a
> key value is written, so it should be similary mentioned.

I confirmed that you are right, changing the subscriber's timezone
setting changes the UTC offset in the recorded string:

-- Conflict 1 recorded with timezone = 'UTC',
-- Conflict 2 recorded with timezone = 'Asia/Tokyo' on the same key:

SELECT replica_identity,
replica_identity->>'ts' = '2025-01-01 00:00:00+00' AS text_match,
(replica_identity->>'ts')::timestamptz = '2025-01-01
00:00:00+00' AS cast_match
FROM pg_conflict.pg_conflict_log_16390;

replica_identity | text_match | cast_match
---------------------------------+------------+------------
{"ts":"2025-01-01 00:00:00+00"} | t | t
{"ts":"2025-01-01 09:00:00+09"} | f | t

I have added timezone to the list in this version.

~

Here is the v91 patch set, which updates the xid field in
local_conflicts to store the 64-bit full transaction ID (xid8).

Rather than converting the 32-bit XID to a FullTransactionId later when
building the conflict log tuple, the patch converts it when the
conflicting tuple is identified, while its buffer is still pinned.

This is necessary for update_deleted: because the dead tuple is not
locked and its buffer pin is released as soon as the scan in finishes,
converting the XID later (if retention is concurrently stopped due to
max_retention_duration) could allow VACUUM to remove the dead tuple and
advance oldestXid past delete_xid, resulting in an incorrect epoch. For
other conflicts (such as update_origin_differs), the tuple remains
locked and pinned through conflict reporting, so this race cannot occur,
but we convert the XID at the conflict detection sites as well to keep
the handling consistent.

The doc has also been updated to note that local_conflicts[].xid is of
type xid8 and that remote_xid can wrap around on the publisher. I didn't
add any new tests, as I couldn't find existing tests that specifically
cover the full XID, so adding one doesn't seem worth it here.

--
Best Regards,
Zhijie Hou