Re: Conflict detection for update_deleted in logical replication
От | Nisha Moond |
---|---|
Тема | Re: Conflict detection for update_deleted in logical replication |
Дата | |
Msg-id | CABdArM7GBa8kXCdOQw4U--tKgapj5j0hAVzL==B3-fkg8Gzmdg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Conflict detection for update_deleted in logical replication (Nisha Moond <nisha.moond412@gmail.com>) |
Список | pgsql-hackers |
On Sat, Aug 30, 2025 at 10:17 AM Nisha Moond <nisha.moond412@gmail.com> wrote: > > On Fri, Aug 29, 2025 at 11:49 AM Zhijie Hou (Fujitsu) > <houzj.fnst@fujitsu.com> wrote: > > > > Here is the new version patch set which also addressed Shveta's comments[1]. > > > > Thanks for the patches here, I tested the v68-001 patch alone, please > find review comments - > Further review comments for v68-0001 patch - 3) v68 seems to have introduced a bug: @@ -1254,9 +1257,12 @@ ApplyLauncherMain(Datum main_arg) /* * Compute the minimum xmin required to protect dead tuples * required for conflict detection among all running apply - * workers that enables retain_dead_tuples. + * workers. */ - if (sub->retaindeadtuples && can_advance_xmin) + if (TransactionIdIsValid(MyReplicationSlot->data.xmin) && + sub->retaindeadtuples && + sub->retentionactive && + can_update_xmin) compute_min_nonremovable_xid(w, &xmin); The new check "TransactionIdIsValid(MyReplicationSlot->data.xmin)" can cause a segmentation fault in the launcher when a default subscription is created (i.e., retain_dead_tuples=off) and the conflict slot does not exist. Perhaps it should first check "sub->retaindeadtuples" before accessing the slot. -- Thanks, Nisha
В списке pgsql-hackers по дате отправления: