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

From Alvaro Herrera
Subject Re: row filtering for logical replication
Date
Msg-id 202107162135.m5ehijgcasjk@alvherre.pgsql
Whole thread Raw
In response to Re: row filtering for logical replication  (Greg Nancarrow <gregn4422@gmail.com>)
Responses Re: row filtering for logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 2021-Jul-16, Greg Nancarrow wrote:

> On Fri, Jul 16, 2021 at 3:50 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > I am not so sure about different filters for old and new rows but it
> > makes sense to by default apply the filter to both old and new rows.
> > Then also provide a way for user to specify if the filter can be
> > specified to just old or new row.
> 
> I'm having some doubts and concerns about what is being suggested.

Yeah.  I think the idea that some updates fail to reach the replica,
leaving the downstream database in a different state than it would be if
those updates had reached it, is unsettling.  It makes me wish we raised
an error at UPDATE time if both rows would not pass the filter test in
the same way -- that is, if the old row passes the filter, then the new
row must be a pass as well.

Maybe a second option is to have replication change any UPDATE into
either an INSERT or a DELETE, if the old or the new row do not pass the
filter, respectively.  That way, the databases would remain consistent.

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/
"You're _really_ hosed if the person doing the hiring doesn't understand
relational systems: you end up with a whole raft of programmers, none of
whom has had a Date with the clue stick."              (Andrew Sullivan)



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [PROPOSAL] new diagnostic items for the dynamic sql
Next
From: Alvaro Herrera
Date:
Subject: Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers