Re: A bug in LWLOCK_STATS

2020-02-05 Thread Fujii Masao
On 2020/02/05 17:13, Julien Rouhaud wrote: On Wed, Feb 05, 2020 at 02:43:49PM +0900, Fujii Masao wrote: Hi, When I compiled PostgreSQL with -DLWLOCK_STATS and tried to check the statistics of light-weight locks, I observed that more than one statistics entries were output *for the same backe

Re: A bug in LWLOCK_STATS

2020-02-05 Thread Kyotaro Horiguchi
At Wed, 5 Feb 2020 14:43:49 +0900, Fujii Masao wrote in > The cause of this issue is that the key variable used for lwlock hash > table was not fully initialized. The key consists of two fields and > they are initialized as follows. But the following 4 bytes allocated > for the alignment was not

Re: A bug in LWLOCK_STATS

2020-02-05 Thread Julien Rouhaud
On Wed, Feb 05, 2020 at 02:43:49PM +0900, Fujii Masao wrote: > Hi, > > When I compiled PostgreSQL with -DLWLOCK_STATS and tried to check > the statistics of light-weight locks, I observed that more than one > statistics entries were output *for the same backend process and > the same lwlock*. For

A bug in LWLOCK_STATS

2020-02-04 Thread Fujii Masao
Hi, When I compiled PostgreSQL with -DLWLOCK_STATS and tried to check the statistics of light-weight locks, I observed that more than one statistics entries were output *for the same backend process and the same lwlock*. For example, I got the following four statistics when I checked how the proc