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

From Stephen Frost
Subject Re: row filtering for logical replication
Date
Msg-id 20181123190330.GI3415@tamriel.snowman.net
Whole thread Raw
In response to Re: row filtering for logical replication  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Responses Re: row filtering for logical replication
List pgsql-hackers
Greetings,

* Fabrízio de Royes Mello (fabriziomello@gmail.com) wrote:
> On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek <petr.jelinek@2ndquadrant.com>
> wrote:
> > > If carefully documented I see no problem with it... we already have an
> > > analogous problem with functional indexes.
> >
> > The difference is that with functional indexes you can recreate the
> > missing object and everything is okay again. With logical replication
> > recreating the object will not help.
> >
>
> In this case with logical replication you should rsync the object. That is
> the price of misunderstanding / bad use of the new feature.
>
> As usual, there are no free beer ;-)

There's also certainly no shortage of other ways to break logical
replication, including ways that would also be hard to recover from
today other than doing a full resync.

What that seems to indicate, to me at least, is that it'd be awful nice
to have a way to resync the data which doesn't necessairly involve
transferring all of it over again.

Of course, it'd be nice if we could track those dependencies too,
but that's yet another thing.

In short, I'm not sure that I agree with the idea that we shouldn't
allow this and instead I'd rather we realize it and put the logical
replication into some kind of an error state that requires a resync.

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 64-bit hash function for hstore and citext data type
Next
From: Tom Lane
Date:
Subject: Re: 64-bit hash function for hstore and citext data type