On Wed, Jun 24, 2020 at 8:45 PM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > On 2020-Jun-24, Fujii Masao wrote: > > > On 2020/06/24 8:39, Alvaro Herrera wrote: > > > > I think we should publish the value from wal_keep_segments separately > > > from max_slot_wal_keep_size. ISTM that the user might decide to change > > > or remove wal_keep_segments and be suddenly at risk of losing slots > > > because of overlooking that it was wal_keep_segments, not > > > max_slot_wal_keep_size, that was protecting them. > > > > You mean to have two functions that returns > > > > 1. "current WAL LSN - wal_keep_segments * 16MB" > > 2. "current WAL LSN - max_slot_wal_keep_size" > > Hmm, but all the values there are easily findable. What would be the > point in repeating it? > > Maybe we should disregard this line of thinking and go back to > Horiguchi-san's original proposal, to wit use the "distance to > breakage", as also supported now by Amit Kapila[1] (unless I > misunderstand him). >
+1. I also think let's drop the idea of exposing a function for this value and revert the min_safe_lsn part of the work as proposed by Michael above [1] excluding the function pg_wal_oldest_lsn() in that patch. Then, we can expose this as a new stat for PG14. I feel it would be better to display this stat in a new view (something like pg_stat_replication_slots) as discussed in another thread [2]. Does that make sense? [1] - https://www.postgresql.org/message-id/20200622054950.GC50978%40paquier.xyz [2] - https://www.postgresql.org/message-id/CA%2Bfd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg%40mail.gmail.com -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
