On 2020/05/14 0:38, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> I think it counts as a variable with "static storage duration" per 6.7.8
>> (para 10), see [1]. I wasn't aware of this either, but it probably means
>> the memset is unnecessary.
>> Also, it seems a bit strange/confusing to handle this differently from
>> BgWriterStats. And that worked fine without the init for years ...
>
> Yeah, exactly.
>
> There might be merit in memsetting it if we thought that it could have
> become nonzero in the postmaster during a previous shmem cycle-of-life.
> But the postmaster really shouldn't be accumulating such counts; and
> if it is, then we have a bigger problem, because child processes would
> be inheriting those counts via fork.
In my previous test, I thought I observed that the counters are already
updated at the beginning of some processes. So I thought that
the counters need to be initialized. Sorry, that's my fault...
So I tried the similar test again and found that postmaster seems to be
able to increment the counters unless I'm missing something.
For example,
frame #2: 0x000000010d93845f postgres`pgstat_count_slru_page_zeroed(ctl=0x000000010de27320) at pgstat.c:6739:2
frame #3: 0x000000010d5922ba postgres`SimpleLruZeroPage(ctl=0x000000010de27320, pageno=0) at slru.c:290:2
frame #4: 0x000000010d6b9ae2 postgres`AsyncShmemInit at async.c:568:12
frame #5: 0x000000010d9da9a6 postgres`CreateSharedMemoryAndSemaphores at ipci.c:265:2
frame #6: 0x000000010d93f679 postgres`reset_shared at postmaster.c:2664:2
frame #7: 0x000000010d93d253 postgres`PostmasterMain(argc=3, argv=0x00007fad56402e00) at postmaster.c:1008:2
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION