> 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/
