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

From kedar anavardekar
Subject Re: Proposal: Conflict log history table for Logical Replication
Date
Msg-id CAJZSXGpp46n6VOnEsqod9b3dz+Z45dxoqcPcyEWTA9T5WYf9tw@mail.gmail.com
Whole thread
In response to Re: Proposal: Conflict log history table for Logical Replication  (Nisha Moond <nisha.moond412@gmail.com>)
Responses Re: Proposal: Conflict log history table for Logical Replication
List pgsql-hackers
This is a slightly different topic than the one discussed in the email.

opposite to what mentioned in the docs:
+     If a key value is larger than 1kB it is not recorded.  In its place the
+     conflict log stores a small object marking it as omitted and giving its
+     size, and sets <literal>has_omitted_values</literal> for that row:
+<programlisting>
+ {"id":"1","tag":"abc","doc":{"omitted":true,"length":4096}}
+</programlisting>
+     Large values are dropped rather than shortened, because a shortened value
+     would still look like a real one and would give wrong answers when
+     compared or joined against the table.

For the case you mentioned in Case:A, the oversized value is PK itself and
 The contents logged to the CLT are like:

relid | conflict_type  | replica_identity_full |
replica_identity              | local_conflicts | has_om
itted_values
-------+----------------+-----------------------+-------------------------------------------+-----------------+-------
-------------
 16432 | delete_missing | f                     |
{"b":{"omitted":true,"length":200000000}} |                 | t

Would logging a shortened value or preview (which would fit within the column
size limits) to the CLT provide more information or value to the user?

As from the current information which is getting logged as shown above
user might not get useful
information about the conflict.
--
Thanks & Regards,
Kedar


> Thoughts?



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: on_error table, saving error info to a table
Next
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH v1] Fix out-of-bounds access in pg_bsd_indent's parser stack