| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
| Cc: | Shinya Kato <shinya11(dot)kato(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Subject: | Re: Fix lag columns in pg_stat_replication not advancing when replay LSN stalls |
| Date: | 2025-10-22 02:34:13 |
| Message-ID: | CAHGQGwF3SpdEYC7=Og+9ZvRX09=TDNPh=ChGmFMJGCvckBmWnw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 21, 2025 at 11:52 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> The patch LGTM.
Thanks for the review!
I've pushed the patch and backpatched it to all supported versions.
> I am wondering whether it is helpful to add some
> comments for this overflowed array
Yes, do you have any specific suggestions?
> and replacing literal zeros with the constant InvalidXLogRecPtr for
> better readability.
>
> /* InvalidXLogRecPtr means no overflow yet */
> if (lag_tracker->overflowed[i].lsn == InvalidXLogRecPtr)
I couldn't find any code like "lag_tracker->overflowed[i].lsn == 0",
so I'm not sure which part should be replaced with InvalidXLogRecPtr.
Could you point me to the exact location?
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2025-10-22 02:39:41 | Re: Why cannot alter a column's type when it's used by a generated column |
| Previous Message | Peter Smith | 2025-10-22 02:21:50 | Re: Logical Replication of sequences |