From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
---|---|
To: | Shubham Shingne <shubham(dot)s(dot)shingne(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Limit of WAL LSN value of type pg_lsn |
Date: | 2022-10-31 12:55:13 |
Message-ID: | CAExHW5u94n4NRZm312iy3ypOtT-1anXkdV1zLLoRML9jO0XAfw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Shubham,
On Mon, Oct 31, 2022 at 11:04 AM Shubham Shingne
<shubham(dot)s(dot)shingne(at)gmail(dot)com> wrote:
>
> Hi all,
>
> I am trying to determine optimal standby for automatic failover based on pg_last_wal_recieve_lsn() value of all slaves.
>
> But what if max_wal_size is reached, is LSN value reset to zero.
Per https://www.postgresql.org/docs/current/runtime-config-wal.html
max_wal_size affects how frequently checkpoints are run. It doesn't
specify the limit on WAL produced by a given server. Probably
max_wal_size is a misnomer.
LSN is never reset to zero AFAIU.
>
> Please share some documentation that mentions clarification.
>
> Also suggest if there is any better approach to get node with best RPO out of all slaves.
It depends upon the method used to maintain slaves. Googling "RPO
postgresql" provides a lot of links. I found
http://www.postgresql-blog.com/postgresql-backup-strategy-recovery-pitr-wal/
to be a good start. But there are many others which seem to be useful
too.
--
Best Wishes,
Ashutosh Bapat
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-10-31 13:14:10 | Re: Simplifying our Trap/Assert infrastructure |
Previous Message | Aleksander Alekseev | 2022-10-31 12:49:37 | Re: ResourceOwner refactoring |