At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila <amit.kapil...@gmail.com> wrote in > On Thu, Jun 18, 2020 at 11:52 AM Kyotaro Horiguchi > <horikyota....@gmail.com> wrote: > > > > At Wed, 17 Jun 2020 21:37:55 +0900, Fujii Masao > > <masao.fu...@oss.nttdata.com> wrote in > > > On 2020/06/15 16:35, Kyotaro Horiguchi wrote: > > > Isn't it better to use 1 as the second argument of the above, > > > in order to address the issue that I reported upthread? > > > Otherwise, the WAL file name that pg_walfile_name(min_safe_lsn) > > > returns > > > would be confusing. > > > > Mmm. pg_walfile_name seems too specialize to > > pg_stop_backup(). (pg_walfile_name_offset() returns wrong result for > > segment boundaries.) I'm not willing to do that only to follow such > > suspicious(?) specification, but surely it would practically be better > > doing that. Please find the attached first patch. > > > > It is a little unclear to me how this or any proposed patch will solve > the original problem reported by Fujii-San? Basically, the problem > arises because we don't have an interlock between when the checkpoint > removes the WAL segment and the view tries to acquire the same. Am, I > missing something?
I'm not sure, but I don't get the point of blocking WAL segment removal until the view is completed. The said columns of the view are just for monitoring, which needs an information snapshot seemingly taken at a certain time. And InvalidateObsoleteReplicationSlots kills walsenders using lastRemovedSegNo of a different time. The two are independent each other. Also the patch changes min_safe_lsn to show an LSN at segment boundary + 1. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
