Re: min_safe_lsn column in pg_replication_slots view

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(dot)kapila16(at)gmail(dot)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