RE: Conflict detection for update_deleted in logical replication

From: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Conflict detection for update_deleted in logical replication
Date: 2025-06-23 10:50:09
Message-ID: OS0PR01MB5716C90808F44DF036145E189479A@OS0PR01MB5716.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 23, 2025 at 3:02 PM Amit Kapila wrote:
>
> On Fri, Jun 20, 2025 at 4:48 PM Zhijie Hou (Fujitsu)
> <houzj(dot)fnst(at)fujitsu(dot)com>
> wrote:
> >
> > Here is the V39 patch set which includes the following changes:
> >
>
> 1.
> -static void
> -create_conflict_slot_if_not_exists(void)
> +void
> +ApplyLauncherCreateConflictDetectionSlot(void)
>
> I am not so sure about adding ApplyLauncher in front of this function
> name. I see most others exposed from this file add such a prefix, but
> this one looks odd to me as it has nothing specific to the launcher, though we use it in launcher?
> How about CreateConflictDetectionSlot(void)?

Agreed and changed as suggested.

>
> 2.
> static void
> create_logical_replication_slots(void)
> {
> + if (!count_old_cluster_logical_slots())
> + return;
> +
>
> Doing this count twice (once here and once at the caller of
> create_logical_replication_slots) seems redundant.

I have changed to check the slot numbers before entering the function and
declared a flag to save the results of Count_old_xxslots() function to avoid
counting it twice.

>
> Apart from the above, attached please find a diff patch atop 0001,
> 0002, 0003. I think the first three patches look in a reasonable shape
> now, can we merge them (0001, 0002, 0003)?

Thanks for the diff, it looks good to me.

I have merged 0001~0003 and the diff.

Here is the V40 patch set which includes the following changes:

0001:
* Merged V39-0001 ~ 0003 into one patch.
* Addressed the comments above.
* Addressed Shveta's comments[1].

0002:
No change

0003:
No change

0004:
No change

0005:
No change

0006:
No change

[1] https://www.postgresql.org/message-id/CAJpy0uChWC4MLt_d8EwmKRrYKQYfVQKJrng4KVgktr5v25HP5w%40mail.gmail.com

Best Regards,
Hou zj

Attachment Content-Type Size
v40-0001-Retain-the-information-useful-for-detecting-conf.patch application/octet-stream 168.7 KB
v40-0002-Introduce-a-new-GUC-max_conflict_retention_durat.patch application/octet-stream 29.3 KB
v40-0003-Re-create-the-replication-slot-if-the-conflict-r.patch application/octet-stream 7.0 KB
v40-0004-Add-a-tap-test-to-verify-the-management-of-the-n.patch application/octet-stream 8.0 KB
v40-0005-Support-the-conflict-detection-for-update_delete.patch application/octet-stream 29.4 KB
v40-0006-Allow-altering-retain_conflict_info-for-enabled-.patch application/octet-stream 28.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2025-06-23 10:55:06 Re: Batch TIDs lookup in ambulkdelete
Previous Message Aleksander Alekseev 2025-06-23 10:42:32 Re: [PATCH] pg_bsd_indent: improve formatting of multiline comments