Re: About to add WAL write/fsync statistics to pg_stat_wal view

On 2021/03/25 11:50, Masahiro Ikeda wrote:
>
>
> On 2021/03/23 16:10, Fujii Masao wrote:
>>
>>
>> On 2021/03/22 20:25, ikedamsh wrote:
>>> Agreed. Users can know whether the stats is for walreceiver or not. The
>>> pg_stat_wal view in standby server shows for the walreceiver, and in primary
>>> server it shows for the others. So, I updated the document.
>>> (v20-0003-Makes-the-wal-receiver-report-WAL-statistics.patch)
>>
>> Thanks for updating the docs!
>>
>> There was the discussion about when the stats collector is invoked, at [1].
>> Currently during archive recovery or standby, the stats collector is
>> invoked when the startup process reaches the consistent state, sends
>> PMSIGNAL_BEGIN_HOT_STANDBY, and then the system is starting accepting
>> read-only connections. But walreceiver can be invoked at earlier stage.
>> This can cause walreceiver to generate and send the statistics about WAL
>> writing even though the stats collector has not been running yet. This might
>> be problematic? If so, maybe we need to ensure that the stats collector is
>> invoked before walreceiver?
>>
>> During recovery, the stats collector is not invoked if hot standby mode is
>> disabled. But walreceiver can be running in this case. So probably we should
>> change walreceiver so that it's invoked even when hot standby is disabled?
>> Otherwise we cannnot collect the statistics about WAL writing by walreceiver
>> in that case.
>>
>> [1]
>> https://postgr.es/m/e5a982a5-8bb4-5a10-cf9a-40dd1921bdb5@oss.nttdata.com
>
> Thanks for comments! I didn't notice that.
> As I mentioned[1], if my understanding is right, this issue seem to be not for
> only the wal receiver.
>
> Since the shared memory thread already handles these issues, does this patch,
> which to collect the stats for the wal receiver and make a common function for
> writing wal files, have to be committed after the patches for share memory
> stats are committed? Or to handle them in this thread because we don't know
> when the shared memory stats patches will be committed.
>
> I think the former is better because to collect stats in shared memory is very
> useful feature for users and it make a big change in design. So, I think it's
> beneficial to make an effort to move the shared memory stats thread forward
> (by reviewing or testing) instead of handling the issues in this thread.

Sounds reasonable. Agreed.

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION