Re: min_safe_lsn column in pg_replication_slots view

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: amit(dot)kapila16(at)gmail(dot)com
Cc: michael(at)paquier(dot)xyz, masao(dot)fujii(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: min_safe_lsn column in pg_replication_slots view
Date: 2020-06-19 05:35:11
Message-ID: 20200619.143511.141515868437188926.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Fri, 19 Jun 2020 09:09:03 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in
> On Fri, Jun 19, 2020 at 8:44 AM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> >
> > At Fri, 19 Jun 2020 10:39:58 +0900, Michael Paquier <michael(at)paquier(dot)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?

When max_slot_wal_keep_size is set, the slot may retain up to as many
as that amount of old WAL segments then suddenly loses the oldest
segments. *I* thought that I would use it in an HA cluster tool to
inform users about the remaining time (not literally, of course) a
disconnected standy is allowed diconnected. Of course even if some
segments have been lost, they could be copied from the primary's
archive so that's not critical in theory.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-06-19 05:42:41 Re: Fast DSM segments
Previous Message Bharath Rupireddy 2020-06-19 05:29:38 Re: Cleanup - Removal of unused function parameter from CopyReadBinaryAttribute