Re: Proposal: Conflict log history table for Logical Replication

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Zhijie Hou <houzhijie22(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, shihao zhong <zhong950419(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, saurabh singh <saurabh(dot)singh214(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shvetamalik(at)gmail(dot)com>
Subject: Re: Proposal: Conflict log history table for Logical Replication
Date: 2026-11-04 23:00:03
Message-ID: CAHut+PucAHDiZ6KjaubSB1NKn7Y1wqYLa+cjzLdE=7HEh=zxhA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 4, 2026 at 9:29 PM Zhijie Hou <houzhijie22(at)gmail(dot)com> wrote:
>
> 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.
>

I found one more setting that can affect how a key is written: lc_monetary.

It's probably unlikely, and I can only cause the CLT issue when
binary=true (otherwise the text money value is replicated and a money
conversion ERROR happens instead of a CLT conflict). OTOH, it was
still possible to cause different values, putting lc_monetary in the
same category as other settings that are already documented.

e.g.
-- Conflict 1 recorded with lc_monetary = 'C',
-- Conflict 2 recorded with lc_monetary = 'en_GB.UTF-8', on the same key:

test_sub=# select * from pg_conflict.pg_conflict_log_16486;
relid | schemaname | relname | conflict_type | remote_xid |
remote_commit_lsn | remote_commit_ts | apply_orig
in | replica_identity_full | replica_identity | local_conflicts |
has_omitted_values
-------+------------+---------+----------------+------------+-------------------+-------------------------------+-----------
---+-----------------------+----------------------+-----------------+--------------------
16458 | public | t | delete_missing | 729 |
0/01C7DA18 | 2026-11-04 17:10:35.416412-05 | pg_16486
| f | {"amount":"$123.45"} | | f
16458 | public | t | delete_missing | 731 |
0/01C7DBB8 | 2026-11-04 17:11:59.635981-05 | pg_16486
| f | {"amount":"£123.45"} | | f
(2 rows)

======
Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ethan Tran 2026-11-04 23:05:00 Re: [PATCH]Fix planner's strictness check for JsonExpr
Previous Message Heikki Linnakangas 2026-11-04 22:45:25 Re: enhancing pg_basebackup speeds up to ~23Gbps (small fixes + io_uring/Direct I/O)