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
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 |