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

From Michael Paquier
Subject Re: min_safe_lsn column in pg_replication_slots view
Date
Msg-id 20200625225350.GA1504@paquier.xyz
Whole thread Raw
In response to Re: min_safe_lsn column in pg_replication_slots view  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: min_safe_lsn column in pg_replication_slots view  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Thu, Jun 25, 2020 at 11:24:27AM -0400, Alvaro Herrera wrote:
> I don't understand the proposal.  Michael posted a patch that adds
> pg_wal_oldest_lsn(), and you say we should apply the patch except the
> part that adds that function -- so what part would be applying?

I have sent last week a patch about only the removal of min_safe_lsn:
https://www.postgresql.org/message-id/20200619121552.GH453547@paquier.xyz
So this applies to this part.

> If the proposal is to apply just the hunk in pg_get_replication_slots
> that removes min_safe_lsn, and do nothing else in pg13, then I don't like
> it.  The feature exposes a way to monitor slots w.r.t. the maximum slot
> size; I'm okay if you prefer to express that in a different way, but I
> don't like the idea of shipping pg13 without any way to monitor it.

From what I can see, it seems to me that we have a lot of views of how
to tackle the matter.  That gives an idea that we are not really happy
with the current state of things, and usually a sign that we may want
to redesign it, going back to this issue for v14.

My 2c.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Default setting for enable_hashagg_disk
Next
From: Bruce Momjian
Date:
Subject: Re: should libpq also require TLSv1.2 by default?