Re: logical replication restrictions
От | Hannu Krosing |
---|---|
Тема | Re: logical replication restrictions |
Дата | |
Msg-id | CAMT0RQRYbKH3K=wLnk47M6iWdF7hChm-b2zamVODe59vTxVQ4Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: logical replication restrictions (Amit Kapila <amit.kapila16@gmail.com>) |
Список | 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 по дате отправления: