From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: confusion between max_standby_archive_delay, max_standby_archive_delay and max_standby_archive_delay |
Date: | 2023-03-11 20:54:18 |
Message-ID: | a49b2087-ffb3-7360-1803-c1a99b59237a@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 3/11/23 14:23, Atul Kumar wrote:
> Hi,
>
> Could someone help me in telling the difference between these
> three parameters
> 1. max_standby_archive_delay
> 2. max_standby_streaming_delay
> 3. recovery_min_apply_delay
>
> My basic motive is to make the standby database server to be delayed to
> apply the changes on itself, if any data has been accidentally
> deleted/updated/ truncated from the primary server.
What you're looking for is that WAL files be "aggregated and *optimized*" by
removing statements which don't have any impact on the final state of instance.
That's great for *restoring* instances with update-heavy databases, and can
only implemented by backup/restore software, or roll-your-own log shipping.
Just as importantly, that aggregation-optimization software has it's own
costs (time and disk space), since it takes time to scan through all the
recovery logs, keeping track of what must stay, what can be tossed, and the
final state.
--
Born in Arizona, moved to Babylonia.
From | Date | Subject | |
---|---|---|---|
Next Message | Erwin Brandstetter | 2023-03-11 23:49:43 | Re: Idea: Add first() and last() aggregate functions to the main release |
Previous Message | Atul Kumar | 2023-03-11 20:23:44 | confusion between max_standby_archive_delay, max_standby_archive_delay and max_standby_archive_delay |