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

From Petr Jelinek
Subject Re: row filtering for logical replication
Date
Msg-id 8c88c6ac-2d34-e577-0aa3-2a190ae0f4f7@2ndquadrant.com
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  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List 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.jelinek@2ndquadrant.com <mailto: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 ;-)
> 

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 64-bit hash function for hstore and citext data type
Next
From: Tomas Vondra
Date:
Subject: Re: row filtering for logical replication