Re: logical replication restrictions - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: logical replication restrictions
Date
Msg-id CAMT0RQRYbKH3K=wLnk47M6iWdF7hChm-b2zamVODe59vTxVQ4Q@mail.gmail.com
Whole thread Raw
In response to Re: logical replication restrictions  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Wed, Sep 22, 2021 at 6:18 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, Sep 21, 2021 at 4:21 PM Marcos Pegoraro <marcos@f10.com.br> wrote:
>>
>> No, I´m talking about that configuration you can have on standby servers
>> recovery_min_apply_delay = '8h'
>>
>
> oh okay, I think this can be useful in some cases where we want to avoid data loss similar to its use for physical
standby.For example, if the user has by mistake truncated the table (or deleted some required data) on the publisher,
wecan always it from the subscriber if we have such a feature. 
>
> Having said that, I am not sure if we can call it a restriction. It is more of a TODO kind of thing. It doesn't sound
advisableto me to keep growing the current Restrictions page [1]. 

One could argue that not having delayed apply *is* a restriction
compared to both physical replication and "the original upstream"
pg_logical.

I think therefore it should be mentioned in "Restrictions"  so people
considering moving from physical streaming to pg_logical or just
trying to decide whether to use pg_logical are warned.

Also, the Restrictions page starts with " These might be addressed in
future releases." so there is no exclusivity of being either a
restriction or TODO.

> [1] - https://wiki.postgresql.org/wiki/Todo
> [2] - https://www.postgresql.org/docs/devel/logical-replication-restrictions.html


-----
Hannu Krosing
Google Cloud - We have a long list of planned contributions and we are hiring.
Contact me if interested.



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: extended stats on partitioned tables
Next
From: Justin Pryzby
Date:
Subject: Re: extended stats on partitioned tables