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:2Umm. 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
