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.
Kind Regards,
Peter Smith.
Fujitsu Australia
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 |