Re: row filtering for logical replication

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: row filtering for logical replication
Дата
Msg-id 20181123190330.GI3415@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: row filtering for logical replication  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Ответы Re: row filtering for logical replication  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: 64-bit hash function for hstore and citext data type
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 64-bit hash function for hstore and citext data type