From: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Conflict detection for update_deleted in logical replication |
Date: | 2024-10-21 03:09:59 |
Message-ID: | OS0PR01MB57165AABBBF3C7E001571E2894432@OS0PR01MB5716.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Friday, October 18, 2024 5:47 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Oct 11, 2024 at 2:04 PM Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com>
> wrote:
> >
> >
> > Attach the V4 patch set which addressed above comments.
> >
>
> A few minor comments:
Thanks for the comments.
> 1.
> + * Retaining the dead tuples for this period is sufficient because any
> + * subsequent transaction from the publisher will have a later timestamp.
> + * Therefore, it is acceptable if dead tuples are removed by vacuum and
> +an
> + * update_missing conflict is detected, as the correct resolution for
> +the
> + * last-update-wins strategy in this case is to convert the UPDATE to
> +an INSERT
> + * and apply it anyway.
> + *
> + * The 'remote_wal_pos' will be reset after sending a new request to
> walsender.
> + */
> +static void
> +maybe_advance_nonremovable_xid(XLogRecPtr *remote_wal_pos,
> + DeadTupleRetainPhase *phase)
>
> We should cover the key point of retaining dead tuples which is to avoid
> converting updates to inserts (considering the conflict as
> update_missing) in the comments above and also in the commit message.
Right, I updated the comments the commit messages for the same.
>
> 2. In maybe_advance_nonremovable_xid() all three phases are handled by
> different if blocks but as per my understanding the phase value will be unique
> in one call to the function. So, shouldn't it be handled with else if?
I thought that it is possible that we can immediately pass the check in next phase,
thus, wanted to run the codes of next phase as well during one function call.
For example, after switching from DTR_WAIT_FOR_LOCAL_FLUSH to
DTR_REQUEST_WALSENDER_WAL_POS, it’s possible that enough time have passed since
the last wal position request, so It was intended to let it immediately send
the next request in the next if block if possible.
I added some comments in this version to make it clear.
Here is the V5 patch set which addressed above comments.
Best Regards,
Hou zj
Attachment | Content-Type | Size |
---|---|---|
v5-0005-Add-a-tap-test-to-verify-the-new-slot-xmin-mechan.patch | application/octet-stream | 6.8 KB |
v5-0001-Maintain-the-oldest-non-removeable-tranasction-id.patch | application/octet-stream | 17.8 KB |
v5-0002-Maintain-the-replication-slot-in-logical-launcher.patch | application/octet-stream | 11.4 KB |
v5-0003-Support-the-conflict-detection-for-update_deleted.patch | application/octet-stream | 20.8 KB |
v5-0004-Add-a-detect_update_deleted-option-to-subscriptio.patch | application/octet-stream | 63.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michel Pelletier | 2024-10-21 03:29:13 | Re: Using Expanded Objects other than Arrays from plpgsql |
Previous Message | Michael Paquier | 2024-10-21 02:32:23 | Re: report a typo in WaitReadBuffers |