From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
Cc: | petr(dot)jelinek(at)2ndquadrant(dot)com, Euler Taveira de Oliveira <euler(at)timbira(dot)com(dot)br>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, hironobu(at)interdb(dot)jp |
Subject: | Re: row filtering for logical replication |
Date: | 2018-11-23 19:03:30 |
Message-ID: | 20181123190330.GI3415@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Fabrízio de Royes Mello (fabriziomello(at)gmail(dot)com) wrote:
> On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-11-23 19:05:17 | Re: 64-bit hash function for hstore and citext data type |
Previous Message | Tom Lane | 2018-11-23 18:45:47 | Re: 64-bit hash function for hstore and citext data type |