| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: logical replication restrictions |
| Date: | 2021-09-22 04:18:12 |
| Message-ID: | CAA4eK1KSBGrLKR63iS38Bkvjq6fBCWzbuD6R15kEWdmd8aj3mw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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].
[1] - https://wiki.postgresql.org/wiki/Todo
[2] -
https://www.postgresql.org/docs/devel/logical-replication-restrictions.html
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | osumi.takamichi@fujitsu.com | 2021-09-22 04:39:58 | RE: Failed transaction statistics to measure the logical replication progress |
| Previous Message | Ajin Cherian | 2021-09-22 04:05:15 | Re: row filtering for logical replication |