From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: min_safe_lsn column in pg_replication_slots view |
Date: | 2020-06-23 06:20:34 |
Message-ID: | CAA4eK1JS_sDk4NJewjK_F=huBM0+-xJDg=m3531Gfdg7CQsQpw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 22, 2020 at 6:32 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>
> On 2020/06/22 21:01, Amit Kapila wrote:
> > On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> >>
> >> On Sat, Jun 20, 2020 at 03:53:54PM +0900, Michael Paquier wrote:
> >>> On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila wrote:
> >>>> Isn't this information specific to checkpoints, so maybe better to
> >>>> display in view pg_stat_bgwriter?
> >>>
> >>> Not sure that's a good match. If we decide to expose that, a separate
> >>> function returning a LSN based on the segment number from
> >>> XLogGetLastRemovedSegno() sounds fine to me, like
> >>> pg_wal_last_recycled_lsn(). Perhaps somebody has a better name in
> >>> mind?
> >>
> >> I was thinking on this one for the last couple of days, and came up
> >> with the name pg_wal_oldest_lsn(), as per the attached, traking the
> >> oldest WAL location still available.
>
> Thanks for the patch!
>
> + <literal>NULL</literal> if no WAL segments have been removed since
> + startup.
>
> Isn't this confusing? I think that we should store the last removed
> WAL segment to somewhere (e.g., pg_control) and restore it at
> the startup, so that we can see the actual value even after the startup.
> Or we should scan pg_wal directory and find the "minimal" WAL segment
> and return its LSN.
>
>
> > I feel such a function is good to have but I am not sure if there is a
> > need to tie it with the removal of min_safe_lsn column.
>
> We should expose the LSN calculated from
> "the current WAL LSN - max(wal_keep_segments * 16MB, max_slot_wal_keep_size)"?
> This indicates the minimum LSN of WAL files that are guaraneed to be
> currently retained by wal_keep_segments and max_slot_wal_keep_size.
> That is, if checkpoint occurs when restart_lsn of replication slot is
> smaller than that minimum LSN, some required WAL files may be removed.
>
> So DBAs can periodically monitor and compare restart_lsn and that minimum
> LSN. If they see frequently that difference of those LSN is very small,
> they can decide to increase wal_keep_segments or max_slot_wal_keep_size,
> to prevent required WAL files from being removed. Thought?
>
+1. This sounds like a good and useful stat for users.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2020-06-23 06:25:09 | Re: xid wraparound danger due to INDEX_CLEANUP false |
Previous Message | James Sewell | 2020-06-23 06:01:51 | Re: Threading in BGWorkers (!) |