public inbox for [email protected]  

help / color / mirror / Atom feed

From: Chao Li <[email protected]>
To: Zhijie Hou (Fujitsu) <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Amit Kapila <[email protected]>
Subject: Re: Fix stats reporting delays in logical parallel apply worker
Date: Fri, 17 Apr 2026 15:40:40 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <TYRPR01MB141956D9C159D7B867A9F2AEE94202@TYRPR01MB14195.jpnprd01.prod.outlook.com>
References: <TYRPR01MB1419579F217CC4332B615589594202@TYRPR01MB14195.jpnprd01.prod.outlook.com>
	<TYRPR01MB141956D9C159D7B867A9F2AEE94202@TYRPR01MB14195.jpnprd01.prod.outlook.com>



> On Apr 17, 2026, at 11:35, Zhijie Hou (Fujitsu) <[email protected]> wrote:
> 
> On Friday, April 17, 2026 11:01 AM Zhijie Hou (Fujitsu) <[email protected]> wrote:
>> Hi,
>> 
>> When implementing another feature, I noticed that parallel apply workers
>> currently do not report statistics while idle in their main loop. This can cause
>> stats from the last processed transaction to be arbitrarily delayed, especially
>> when there are long gaps between streamed transactions.
>> 
>> The issue is demonstrated in 0002, where a TAP test fails when attempting to
>> collect stats from a parallel apply worker that has no subsequent transaction
>> to
>> trigger a stats report.
>> 
>> 0001 fixes this issue by forcing a stats report when the worker is idle in the
>> main loop, matching the behavior already present in LogicalRepApplyLoop()
>> for
>> regular logical apply workers.
> 
> Regarding 0002, I realized that the streaming option is now set to 'parallel' by
> default so can avoid adjusting the option again. The test needs to be adjusted
> to increase the worker limit so that a parallel worker can start. Here are the
> updated patches.
> 
> Best Regards,
> Hou zj
> <v2-0001-Fix-stats-reporting-delays-in-parallel-apply-work.patch><v2-0002-Test-the-stats-report-in-parallel-apply-worker.patch>

I think WaitLatch will never return WL_LATCH_SET and WL_TIMEOUT together, so we can do “else if (rc & WL_TIMEOUT) && !IsTransactionState())”, so that upon WL_LATCH_SET, it skips the WL_TIMEOUT check, which could be slightly more efficient.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

view thread (7+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Fix stats reporting delays in logical parallel apply worker
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox