Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: Fix stats reporting delays in logical parallel apply worker
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <TYRPR01MB141956D9C159D7B867A9F2AEE94202@TYRPR01MB14195.jpnprd01.prod.outlook.com>
Date: Fri, 17 Apr 2026 15:40:40 +0800
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Amit Kapila <amit.kapila16@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F6FFB88-72EE-4685-BF58-5450FE3D5009@gmail.com>
References: 
 <TYRPR01MB1419579F217CC4332B615589594202@TYRPR01MB14195.jpnprd01.prod.outlook.com>
 <TYRPR01MB141956D9C159D7B867A9F2AEE94202@TYRPR01MB14195.jpnprd01.prod.outlook.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Archived-At: 
 <https://www.postgresql.org/message-id/4F6FFB88-72EE-4685-BF58-5450FE3D5009%40gmail.com>
Precedence: bulk


> On Apr 17, 2026, at 11:35, Zhijie Hou (Fujitsu) =
<houzj.fnst@fujitsu.com> wrote:
>=20
> On Friday, April 17, 2026 11:01 AM Zhijie Hou (Fujitsu) =
<houzj.fnst@fujitsu.com> wrote:
>> Hi,
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
> 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 =E2=80=9Celse if (rc & WL_TIMEOUT) && =
!IsTransactionState())=E2=80=9D, 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/