Re: Conflict detection for update_deleted in logical replication

From: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Conflict detection for update_deleted in logical replication
Date: 2025-09-01 04:02:21
Message-ID: CABdArM7ZmOpCSow0n08xFB36rEwraMiuzCnwx2seyq2nqNbiVg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 28, 2025 at 6:00 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
>
> Test-04. pgbench on both side, and max_conflict_retention_duration was tuned
> ========================================================================
> Setup:
> -------
> Pub --> Sub
> - setup is same as Test-03(above)
> - Additionally, subscription option max_conflict_retention_duration=60s
>
> Workload:
> -------------
> - Run default pgbench(read-write) on both Pub and Sub nodes for their
> respective pgbench tables
> - Started with 15 clients on both sides.
> - When conflict_slot.xmin becomes NULL on Sub, pgbench was paused to
> let the subscription catch up. Then reduced publisher clients by half
> and resumed pgbench. Here, slot.xmin becomes NULL to indicate conflict
> retention is stopped under high publisher load but stays non-NULL when
> Sub is able to catchup with Pub's load.
> - Total duration of pgbench run is 10 minutes (600s).
>
> Observations:
> ------------------
> - Without the parallel apply patch, publisher clients reduced from
> 15->7->3,and finally the retention was not stopped at 3 clients and
> slot.xmin remained non-NULL.
> - With the parallel apply patch, using 2 workers the subscription
> handled up to 7 publisher clients without stopping the conflict
> retention.
> - With 4+ workers, retention continued for the full 10 minutes and
> Sub TPS showed no regression.
>

I repeated the test with 4 parallel workers over a 12-hour pgbench
run. Retention continued for the full duration without stopping, and
no regression was observed on either publisher or subscriber.

Here is the pgbench result for the run on the publisher node -
number of clients: 15
number of threads: 15
maximum number of tries: 1
duration: 43200 s
number of transactions actually processed: 725093972
number of failed transactions: 0 (0.000%)
latency average = 0.893 ms
latency stddev = 1.176 ms
initial connection time = 8.879 ms
tps = 16784.585718 (without initial connection time)
~~~

Subscriber's TPS = 16668.322700

--
Thanks,
Nisha

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexandra Wang 2025-09-01 04:11:08 Re: SQL:2023 JSON simplified accessor support
Previous Message shveta malik 2025-09-01 03:45:40 Re: Issue with logical replication slot during switchover