On Tue, Jun 30, 2020 at 7:53 PM Fujii Masao <masao.fu...@oss.nttdata.com> wrote: > > On 2020/06/30 17:07, Fujii Masao wrote: > > > > > > On 2020/06/26 13:45, Amit Kapila wrote: > >> > >> Can we consider an option to "Remove min_safe_lsn; document how a user > >> can monitor the distance"? We have a function to get current WAL > >> insert location and other things required are available either via > >> view or as guc variable values. The reason I am thinking of this > >> option is that it might be better to get some more feedback on what is > >> the most appropriate value to display. However, I am okay if we can > >> reach a consensus on one of the above options. > > > > Yes, that's an idea. But it might not be easy to calculate that distance > > manually by subtracting max_slot_wal_keep_size from the current LSN. > > Because we've not supported -(pg_lsn, numeric) operator yet. I'm > > proposing that operator, but it's for v14. > > Sorry this is not true. That distance can be calculated without those > operators. > For example, > > SELECT restart_lsn - pg_current_wal_lsn() + (SELECT setting::numeric * 1024 * > 1024 FROM pg_settings WHERE name = 'max_slot_wal_keep_size') distance FROM > pg_replication_slots; > > If the calculated distance is small or negative value, which means that > we may lose some required WAL files. So in this case it's worth considering > to increase max_slot_wal_keep_size. > > I still think it's better and more helpful to display something like > that distance in pg_replication_slots rather than making each user > calculate it... >
Okay, but do we think it is better to display this in pg_replication_slots or some new view like pg_stat_*_slots as being discussed in [1]? It should not happen that we later decide to move this or similar stats to that view. [1] - https://www.postgresql.org/message-id/CA%2Bfd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg%40mail.gmail.com -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com