From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: amit.kapila16@gmail.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: min_safe_lsn column in pg_replication_slots view
Date: Fri, 19 Jun 2020 16:13:27 +0900
Message-ID: <3b016893-9638-4f99-a1d0-bce007e8242a@oss.nttdata.com> (raw)
In-Reply-To: <20200619013958.GC453547@paquier.xyz>
References: <b550159e-8eb3-a0e2-f6e5-cc27d84b4635@oss.nttdata.com>
<20200618.152216.1889381045723164350.horikyota.ntt@gmail.com>
<CAA4eK1Jq8wCMrNWdPBhUfEF3kxLZic9+eyaqN+dRmBxG7fMaUg@mail.gmail.com>
<20200619.100254.2207382472075080858.horikyota.ntt@gmail.com>
<20200619013958.GC453547@paquier.xyz>
On 2020/06/19 10:39, Michael Paquier wrote:
> On Fri, Jun 19, 2020 at 10:02:54AM +0900, Kyotaro Horiguchi wrote:
>> At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in
>>> It is a little unclear to me how this or any proposed patch will solve
>>> the original problem reported by Fujii-San? Basically, the problem
>>> arises because we don't have an interlock between when the checkpoint
>>> removes the WAL segment and the view tries to acquire the same. Am, I
>>> missing something?
>
> The proposed patch fetches the computation of the minimum LSN across
> all slots before taking ReplicationSlotControlLock so its value gets
> more lossy, and potentially older than what the slots actually
> include. So it is an attempt to take the safest spot possible.
>
> Honestly, I find a bit silly the design to compute and use the same
> minimum LSN value for all the tuples returned by
> pg_get_replication_slots, and you can actually get a pretty good
> estimate of that by emulating ReplicationSlotsComputeRequiredLSN()
> directly with what pg_replication_slot provides as we have a min()
> aggregate for pg_lsn.
>
> For these reasons, I think that we should remove for now this
> information from the view, and reconsider this part more carefully for
> 14~ with a clear definition of how much lossiness we are ready to
> accept for the information provided here, if necessary.
Agreed. But isn't it too late to remove the columns (i.e., change
the catalog) for v13? Because v13 beta1 was already released.
IIUC the catalog should not be changed since beta1 release so that
users can upgrade PostgreSQL without initdb.
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, michael@paquier.xyz, horikyota.ntt@gmail.com, amit.kapila16@gmail.com
Subject: Re: min_safe_lsn column in pg_replication_slots view
In-Reply-To: <3b016893-9638-4f99-a1d0-bce007e8242a@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