Re: Allow reading LSN written by walreciever, but not flushed yet

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Jeremy Schneider <schneider(at)ardentperf(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow reading LSN written by walreciever, but not flushed yet
Date: 2025-10-06 09:05:31
Message-ID: 5BBF0BB4-97F6-4787-9FD7-312234CBC7AF@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 6 Oct 2025, at 04:42, Jeremy Schneider <schneider(at)ardentperf(dot)com> wrote:
>
> A large and stressed system could get into a state where fsync takes
> awhile.

For such cases I would like to have a function that ensures walreceiver will not acknowledge any new LSN. And then returns last ack'ed LSN.

Today we have to stop walreceiver, which takes some time from our 9999s.

Best regards, Andrey Borodin.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2025-10-06 09:07:57 Re: Improve read_local_xlog_page_guts by replacing polling with latch-based waiting
Previous Message John Naylor 2025-10-06 09:04:00 get rid of RM_HEAP2_ID