From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Euler Taveira <euler(at)eulerto(dot)com> |
Cc: | Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical replication restrictions |
Date: | 2021-09-23 05:53:25 |
Message-ID: | CAA4eK1L5Y+92qgBqp2ELv611uBHegJwTCRH_0JvW-KpVMDBYnA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 22, 2021 at 10:27 PM Euler Taveira <euler(at)eulerto(dot)com> wrote:
>
> On Wed, Sep 22, 2021, at 1:18 AM, Amit Kapila wrote:
>
> On Tue, Sep 21, 2021 at 4:21 PM Marcos Pegoraro <marcos(at)f10(dot)com(dot)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, we can 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 advisable to me to keep growing the current Restrictions page [1].
>
> It is a new feature. pglogical supports it and it is useful for delayed
> secondary server and if, for some business reason, you have to delay when data
> is available.
>
What kind of reasons do you see where users prefer to delay except to
avoid data loss in the case where users unintentionally removed some
data from the primary?
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2021-09-23 06:28:00 | Re: Asynchronous and "direct" IO support for PostgreSQL. |
Previous Message | Dilip Kumar | 2021-09-23 05:41:23 | Re: Next Steps with Hash Indexes |