Re: min_safe_lsn column in pg_replication_slots view
От | Amit Kapila |
---|---|
Тема | Re: min_safe_lsn column in pg_replication_slots view |
Дата | |
Msg-id | CAA4eK1+BgTzQQBLkxMeD7xh8MgNgT9rmm2F=H-Rx-fN0Rzs4eQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: min_safe_lsn column in pg_replication_slots view (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: min_safe_lsn column in pg_replication_slots view
|
Список | pgsql-hackers |
On Fri, Jun 19, 2020 at 6:32 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > At Thu, 18 Jun 2020 18:18:37 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in > > On Thu, Jun 18, 2020 at 11:52 AM Kyotaro Horiguchi > > <horikyota.ntt@gmail.com> wrote: > > > > > > At Wed, 17 Jun 2020 21:37:55 +0900, Fujii Masao <masao.fujii@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. > I am not suggesting to do that. > 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. > But aren't we doing last_removed_seg+1 even without the patch? See code below - { - XLogRecPtr min_safe_lsn; - - XLogSegNoOffsetToRecPtr(last_removed_seg + 1, 0, - wal_segment_size, min_safe_lsn); With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: