Re: row filtering for logical replication - Mailing list pgsql-hackers

From Peter Smith
Subject Re: row filtering for logical replication
Date
Msg-id CAHut+PsR5NK0sHaZowtEAyjm3o7yf_Ef5_OWOr5gTfiwdDktSg@mail.gmail.com
Whole thread Raw
In response to Re: row filtering for logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, Nov 23, 2021 at 8:02 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Nov 18, 2021 at 11:02 AM Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > On Mon, Nov 15, 2021 at 9:31 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > >
> > > 4. I think we should add some comments in pgoutput_row_filter() as to
> > > why we are caching the row_filter here instead of
> > > get_rel_sync_entry()? That has been discussed multiple times so it is
> > > better to capture that in comments.
> >
> > Added comment in v40 [1]
> >
>
> I think apart from truncate and error cases, it can also happen for
> other operations because we decide whether to publish a change
> (operation) after calling get_rel_sync_entry() in pgoutput_change. I
> think we can reflect that as well in the comment.

Fixed in v42* [1]

------
[1] https://www.postgresql.org/message-id/CAHut%2BPsGZHvafa3K_RAJ0Agm28W2owjNN%2BqU0EUsSjBNbuXFsQ%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel vacuum workers prevent the oldest xmin from advancing
Next
From: Peter Smith
Date:
Subject: Re: row filtering for logical replication