Re: row filtering for logical replication

From: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
To: fabriziomello(at)gmail(dot)com
Cc: 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:14:12
Message-ID: 8c88c6ac-2d34-e577-0aa3-2a190ae0f4f7@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23/11/2018 19:29, Fabrízio de Royes Mello wrote:
>
> On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek
> <petr(dot)jelinek(at)2ndquadrant(dot)com <mailto: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 ;-)
>

Yeah but you have to resync whole subscription, not just single table
(removing table from the publication will also not help), that's pretty
severe punishment. What if you have triggers downstream that do
calculations or logging which you can't recover by simply rebuilding
replica? I think it's better to err on the side of no data loss.

We could also try to figure out a way to recover from this that does not
require resync, ie perhaps we could somehow temporarily force evaluation
of the expression to have current snapshot.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-11-23 20:00:46 Re: row filtering for logical replication
Previous Message Tom Lane 2018-11-23 19:05:17 Re: 64-bit hash function for hstore and citext data type