| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: min_safe_lsn column in pg_replication_slots view |
| Date: | 2020-06-20 06:53:54 |
| Message-ID: | 20200620065354.GA5367@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jun 20, 2020 at 09:45:52AM +0530, Amit Kapila wrote:
> On Sat, Jun 20, 2020 at 7:12 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>> I don't disagree with removing the LSN column, but at the same time we
>> need to provide *some* way for users to monitor this, so let's add a
>> function to extract the value they need for that. It seems simple
>> enough.
>
> Isn't this information specific to checkpoints, so maybe better to
> display in view pg_stat_bgwriter?
Not sure that's a good match. If we decide to expose that, a separate
function returning a LSN based on the segment number from
XLogGetLastRemovedSegno() sounds fine to me, like
pg_wal_last_recycled_lsn(). Perhaps somebody has a better name in
mind?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2020-06-20 07:08:06 | Re: update substring pattern matching syntax |
| Previous Message | Michael Paquier | 2020-06-20 06:46:27 | Re: pg_regress cleans up tablespace twice. |