Re: Fix lag columns in pg_stat_replication not advancing when replay LSN stalls
| От | Xuneng Zhou | 
|---|---|
| Тема | Re: Fix lag columns in pg_stat_replication not advancing when replay LSN stalls | 
| Дата | |
| Msg-id | CABPTF7XshCOGqKQek7zpaxFojP6NoSWt1a2Pe_eKsHM0WLN_KA@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: Fix lag columns in pg_stat_replication not advancing when replay LSN stalls (Fujii Masao <masao.fujii@gmail.com>) | 
| Ответы | 
                	
            		Re: Fix lag columns in pg_stat_replication not advancing when replay LSN stalls
            		
            		 | 
		
| Список | pgsql-hackers | 
Hi, On Wed, Oct 22, 2025 at 10:45 PM Fujii Masao <masao.fujii@gmail.com> wrote: > > On Wed, Oct 22, 2025 at 4:49 PM Xuneng Zhou <xunengzhou@gmail.com> wrote: > > How about something like: > > > > /* > > * Overflow entries for read heads that collide with the write head. > > * > > * When the cyclic buffer fills (write head is about to collide with a read > > * head), we save that read head's current sample here and mark it as using > > * overflow (read_heads[i] = -1). This allows the write head to continue > > * advancing while the overflowed mode continues lag computation using the > > * saved sample. > > * > > * Once the standby's reported LSN advances past the overflow entry's LSN, > > * we transition back to normal buffer-based tracking. > > */ > > LGTM. Thanks! > > I've created a patch adding your suggested comments (attached). > Since this is a follow-up to commit 883a95646a8, which was recently applied > and backpatched to all supported branches, I think we should backpatch > this one as well. Thought? > LGTM. Thanks for the patch! Best, Xuneng
В списке pgsql-hackers по дате отправления: