Re: min_safe_lsn column in pg_replication_slots view
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Fujii Masao <masao.fujii@oss.nttdata.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-06-19T03:39:03Z
Lists: pgsql-hackers
On Fri, Jun 19, 2020 at 8:44 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > At Fri, 19 Jun 2020 10:39:58 +0900, Michael Paquier <michael@paquier.xyz> wrote in > > Honestly, I find a bit silly the design to compute and use the same > > minimum LSN value for all the tuples returned by > > pg_get_replication_slots, and you can actually get a pretty good > > I see it as silly. I think I said upthread that it was the distance > to the point where the slot loses a segment, and it was rejected but > just removing it makes us unable to estimate the distance so it is > there. > IIUC, the value of min_safe_lsn will lesser than restart_lsn, so one can compute the difference of those to see how much ahead the replication slot's restart_lsn is from min_safe_lsn but still it is not clear how user will make any use of it. Can you please explain how the distance you are talking about is useful to users or anyone? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Fix uninitialized value in segno calculation
- b5b4c0fef9fb 14.0 landed
- 794e8e32bb5a 13.0 landed
-
Morph pg_replication_slots.min_safe_lsn to safe_wal_size
- c54b5891f415 13.0 landed
- a8aaa0c786b3 14.0 landed