Re: logical replication restrictions

From: Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>
To: Euler Taveira <euler(at)eulerto(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logical replication restrictions
Date: 2021-09-22 17:22:20
Message-ID: CAB-JLwaHuOJXKCpMKNVL2hJJ3XDavNWvHq=7Mdp9EsedpK1z=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> 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. There might be other use cases but these are the ones I
> regularly
> heard from customers.
>
> BTW, I have a WIP patch for this feature. I didn't have enough time to
> post it
> because it lacks documentation and tests. I'm planning to do it as soon as
> this
> CF ends.
>
> Fine, let me know if you need any help, testing, for example.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-09-22 18:20:50 Re: Release 14 Schedule
Previous Message Greg Sabino Mullane 2021-09-22 16:57:57 Re: PostgreSQL 14 press release draft