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: 
 <TYRPR01MB141955449A42C05BAC4F35BF594202@TYRPR01MB14195.jpnprd01.prod.outlook.com>
Date: Fri, 17 Apr 2026 17:30:14 +0800
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Amit Kapila <amit.kapila16@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <56F4B26D-F9B6-415D-B51A-AC96EA771006@gmail.com>
References: 
 <TYRPR01MB1419579F217CC4332B615589594202@TYRPR01MB14195.jpnprd01.prod.outlook.com>
 <TYRPR01MB141956D9C159D7B867A9F2AEE94202@TYRPR01MB14195.jpnprd01.prod.outlook.com>
 <4F6FFB88-72EE-4685-BF58-5450FE3D5009@gmail.com>
 <TYRPR01MB141955449A42C05BAC4F35BF594202@TYRPR01MB14195.jpnprd01.prod.outlook.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Archived-At: 
 <https://www.postgresql.org/message-id/56F4B26D-F9B6-415D-B51A-AC96EA771006%40gmail.com>
Precedence: bulk


> On Apr 17, 2026, at 17:20, Zhijie Hou (Fujitsu) =
<houzj.fnst@fujitsu.com> wrote:
>=20
> On Friday, April 17, 2026 3:41 PM Chao Li <li.evan.chao@gmail.com> =
wrote:
>>=20
>>> 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>
>>=20
>> 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.
>=20
> I'm not sure we should assume that WaitLatch will set only one flag at =
a time.
> even if that assumption holds for this specific case, handling bit =
flags this way looks a bit odd.
> AFAICS, we don't use this style elsewhere in the code.
> Currently, users of WL_TIMEOUT (in basebackup_throttle.c, =
walreceiver.c, worker.c)
> all use if ... if logic.
>=20
> Best Regards,
> Hou zj

WL_TIMEOUT is not a real event. If we look at the code of WaitLatch:
```
   if (WaitEventSetWait(LatchWaitSet,
                   (wakeEvents & WL_TIMEOUT) ? timeout : -1,
                   &event, 1,
                   wait_event_info) =3D=3D 0)
      return WL_TIMEOUT;
   else
      return event.events;
```
WL_TIMEOUT won=E2=80=99t be union with other events at all.

Anyway, that=E2=80=99s not a big concern.

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