On 2020/05/14 1:14, Alvaro Herrera wrote:
> On 2020-May-14, Fujii Masao wrote:
>
>> 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
>
> Umm. I have the feeling that we'd rather avoid these updates in
> postmaster, per our general rule that postmaster should not touch shared
> memory. However, it might be that it's okay in this case, as it only
> happens just as shmem is being "created", so other processes have not
> yet had any time to mess things up.
But since the counter that postmaster incremented is propagated to
child processes via fork, it should be zeroed at postmaster or the
beginning of child process? Otherwise that counter always starts
with non-zero in child process.
> (IIRC only the Async module is
> doing that.)
Yes, as far as I do the test.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION