From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Amit Kapila <amit.kapila16@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: min_safe_lsn column in pg_replication_slots view
Date: Mon, 22 Jun 2020 22:02:51 +0900
Message-ID: <4700d202-a420-e8e0-becd-aac6ac52dce6@oss.nttdata.com> (raw)
In-Reply-To: <CAA4eK1JBGLnSxaY4xEjDSDZBtTgWmbxA3YfknEZj3cfE5zu51w@mail.gmail.com>
References: <20200619121552.GH453547@paquier.xyz>
<20200620014223.GA7119@alvherre.pgsql>
<CAA4eK1+O2yHQ6O4PYa=zjyazaZcD10SoAtR5DUbMTnC3_b1BxA@mail.gmail.com>
<20200620065354.GA5367@paquier.xyz>
<20200622054950.GC50978@paquier.xyz>
<CAA4eK1JBGLnSxaY4xEjDSDZBtTgWmbxA3YfknEZj3cfE5zu51w@mail.gmail.com>
On 2020/06/22 21:01, Amit Kapila wrote:
> On Mon, Jun 22, 2020 at 11:19 AM Michael Paquier <michael@paquier.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?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: masao.fujii@oss.nttdata.com, amit.kapila16@gmail.com, michael@paquier.xyz, alvherre@2ndquadrant.com, horikyota.ntt@gmail.com
Subject: Re: min_safe_lsn column in pg_replication_slots view
In-Reply-To: <4700d202-a420-e8e0-becd-aac6ac52dce6@oss.nttdata.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox