Re: Single transaction in the tablesync worker?

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Single transaction in the tablesync worker?
Date: 2021-01-23 00:16:43
Message-ID: CAHut+Ptea3iqx7AFAaa=mB3t1eLt2C=zempp=f91hpL__Bqjsw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 22, 2021 at 1:43 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Jan 21, 2021 at 3:47 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Tue, Jan 19, 2021 at 2:32 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> > >
> > > Hi Amit.
> > >
> > > PSA the v17 patch for the Tablesync Solution1.
> > >
> >
> > Thanks for the updated patch. Below are few comments:
> >
>
> One more comment:
>
> In LogicalRepSyncTableStart(), you are trying to remove the slot on
> the failure of copy which won't work if the publisher is down. If that
> happens on restart of tablesync worker, we will retry to create the
> slot with the same name and it will fail because the previous slot is
> still not removed from the publisher. I think the same problem can
> happen if, after an error in tablesync worker and we drop the
> subscription before tablesync worker gets a chance to restart. So, to
> avoid these problems can we use the TEMPORARY slot for tablesync
> workers as previously? If I remember correctly, the main problem was
> we don't know where to start decoding if we fail in catchup phase. But
> for that origins should be sufficient because if we fail before copy
> then anyway we have to create a new slot and origin but if we fail
> after copy then we can use the start_decoding_position from the
> origin. So before copy, we still need to use CRS_USE_SNAPSHOT while
> creating a temporary slot but if we are already in FINISHED COPY state
> at the start of tablesync worker then create a slot with
> CRS_NOEXPORT_SNAPSHOT option and then use origin's start_pos and
> proceed decoding changes from that point onwards similar to how
> currently the apply worker works.
>

OK. Code is modified as suggested in the latest patch [v18].
Now that tablesync slots are temporary, quite a lot of cleanup code
from the previous patch (v17) is no longer required so has been
removed.

----
[v18] = https://www.postgresql.org/message-id/CAHut%2BPvm0R%3DMn_uVN_JhK0scE54V6%2BEDGHJg1WYJx0Q8HX_mkQ%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2021-01-23 00:25:11 Re: Single transaction in the tablesync worker?
Previous Message Tom Lane 2021-01-23 00:10:14 Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits