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. (IIRC only the Async module is doing that.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
