RE: Collect statistics about conflicts in logical replication

From: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Subject: RE: Collect statistics about conflicts in logical replication
Date: 2024-08-29 02:05:49
Message-ID: OS3PR01MB5718787AFE93E98818C415AE94962@OS3PR01MB5718.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, August 29, 2024 8:31 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:

Hi,

> I tried an experiment where I deliberately violated a primary key during initial
> table synchronization.
>
> For example:
...
> test_sub=# 2024-08-29 09:53:57.245 AEST [4345] LOG: logical replication
> apply worker for subscription "sub1" has started
> 2024-08-29 09:53:57.258 AEST [4347] LOG: logical replication table
> synchronization worker for subscription "sub1", table "t1" has started
> 2024-08-29 09:53:57.311 AEST [4347] ERROR: duplicate key value violates
> unique constraint "t1_pkey"
> 2024-08-29 09:53:57.311 AEST [4347] DETAIL: Key (a)=(1) already exists.
> 2024-08-29 09:53:57.311 AEST [4347] CONTEXT: COPY t1, line 1
> ~~~
>
> Notice how after a while there were multiple (15) 'sync_error_count' recorded.
>
> According to the docs: 'insert_exists' happens when "Inserting a row that
> violates a NOT DEFERRABLE unique constraint.". So why are there not the
> same number of 'insert_exists_count' recorded in pg_stat_subscription_stats?

Because this error was caused by COPY instead of an INSERT (e.g., CONTEXT: COPY
t1, line 1), so this is as expected. The doc of conflict counts(
insert_exists_count) has already mentioned that it counts the conflict only *during the
application of changes* which is clear to me that it doesn't count the ones in
initial table synchronization. See the existing apply_error_count where we also
has similar wording(e.g. "an error occurred while applying changes").

Best Regards,
Hou zj

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2024-08-29 02:26:01 Re: Eager aggregation, take 3
Previous Message Richard Guo 2024-08-29 01:54:57 Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.