Re: Time delayed LR (WAS Re: logical replication restrictions)
От | Nathan Bossart |
---|---|
Тема | Re: Time delayed LR (WAS Re: logical replication restrictions) |
Дата | |
Msg-id | 20230307183014.GB3267929@nathanxps13 обсуждение исходный текст |
Ответ на | Re: Time delayed LR (WAS Re: logical replication restrictions) (Önder Kalacı <onderkalaci@gmail.com>) |
Ответы |
Re: Time delayed LR (WAS Re: logical replication restrictions)
|
Список | pgsql-hackers |
On Mon, Mar 06, 2023 at 07:27:59PM +0300, Önder Kalacı wrote: > On the other hand, we already have a similar problem with > recovery_min_apply_delay combined with hot_standby_feedback [1]. > So, that probably is an acceptable trade-off for the pgsql-hackers. > If you use this feature, you should be even more careful. Yes, but it's possible to turn off hot_standby_feedback so that you don't incur bloat on the primary. And you don't need to store hours or days of WAL on the primary. I'm very late to this thread, but IIUC you cannot avoid blocking VACUUM with the proposed feature. IMO the current set of trade-offs (e.g., unavoidable bloat and WAL buildup) would make this feature virtually unusable for a lot of workloads, so it's probably worth exploring an alternative approach. In any case, we probably shouldn't rush this into v16 in its current form. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: