Date: Wed, 13 May 2020 12:14:06 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	Masahiko Sawada <masahiko.sawada@2ndquadrant.com>,
	"tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: SLRU statistics
Message-ID: <20200513161406.GA437@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c3632226-532b-13b7-4938-f93916c781ea@oss.nttdata.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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