On 2020/05/14 0:38, Tom Lane wrote:
Tomas Vondra <tomas.von...@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
