Re: min_safe_lsn column in pg_replication_slots view - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: min_safe_lsn column in pg_replication_slots view
Date
Msg-id CAA4eK1KXx--JXbbasLW_CGgqn_Z5H+cXnuGmqF9rrPPLeSaEow@mail.gmail.com
Whole thread Raw
In response to Re: min_safe_lsn column in pg_replication_slots view  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: min_safe_lsn column in pg_replication_slots view  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Fri, Jun 19, 2020 at 8:44 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> At Fri, 19 Jun 2020 10:39:58 +0900, Michael Paquier <michael@paquier.xyz> wrote in
> > 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
>
> I see it as silly.  I think I said upthread that it was the distance
> to the point where the slot loses a segment, and it was rejected but
> just removing it makes us unable to estimate the distance so it is
> there.
>

IIUC, the value of min_safe_lsn will lesser than restart_lsn, so one
can compute the difference of those to see how much ahead the
replication slot's restart_lsn is from min_safe_lsn but still it is
not clear how user will make any use of it.  Can you please explain
how the distance you are talking about is useful to users or anyone?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "movead.li@highgo.ca"
Date:
Subject: Re: POC and rebased patch for CSN based snapshots
Next
From: Tom Lane
Date:
Subject: Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute