Re: Skipping logical replication transactions on subscriber side

On Tue, Aug 24, 2021 at 10:05 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Tue, Aug 24, 2021 at 11:44 AM tanghy(dot)fnst(at)fujitsu(dot)com
> <tanghy(dot)fnst(at)fujitsu(dot)com> wrote:
> >
> > On Monday, August 23, 2021 11:09 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > >
> > > I've attached updated patches. Please review them.
> > >
> >
> > I tested v10-0001 patch in both streaming and no-streaming more. All tests works well.
> >
> > I also tried two-phase commit feature, the error context was set as expected,
> > but please allow me to propose a fix suggestion on the error description:

Thank you for the suggestion!

> >
> > CONTEXT: processing remote data during "INSERT" for replication target relation
> > "public.test" in transaction 714 with commit timestamp 2021-08-24
> > 13:20:22.480532+08
> >
> > It said "commit timestamp", but for 2pc feature, the timestamp could be "prepare timestamp" or "rollback timestamp", too.
> > Could we make some change to make the error log more comprehensive?
> >
>
> I think we can write something like: (processing remote data during
> "INSERT" for replication target relation "public.test" in transaction
> 714 at 2021-08-24 13:20:22.480532+08). Basically replacing "with
> commit timestamp" with "at". This is similar to what we do
> test_decoding module for transaction timestamp.

+1

> The other idea could
> be we print the exact operation like commit/prepare/rollback which is
> also possible because we have that information while setting context
> info but that might add a bit more complexity which I don't think is
> worth it.

Agreed.

I replaced "with commit timestamp" with "at" and rename 'commit_ts'
field name to 'ts'.

>
> One more point about the v10-0001* patch: From the commit message
> "Add logical changes details to errcontext of apply worker errors.",
> it appears that the context will be added only for the apply worker
> but won't it get added for tablesync worker as well during its sync
> phase (when it tries to catch up with apply worker)?

Right. I've updated the message.

Attached updated version patches. Please review them.

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/