calculation for NUM_FIXED_LWLOCKS - Mailing list pgsql-hackers

From Amit Kapila
Subject calculation for NUM_FIXED_LWLOCKS
Date
Msg-id CAA4eK1JQrxZ15GgsHUFe1Yx7k5-9+k9qqDR=rVkM1DOfKox1pw@mail.gmail.com
Whole thread Raw
Responses Re: calculation for NUM_FIXED_LWLOCKS  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
Currently the calculation for NUM_FIXED_LWLOCKS is as
below, which I think has some problem:

/* Offsets for various chunks of preallocated lwlocks. */

#define BUFFER_MAPPING_LWLOCK_OFFSET NUM_INDIVIDUAL_LWLOCKS


#define LOCK_MANAGER_LWLOCK_OFFSET \

(BUFFER_MAPPING_LWLOCK_OFFSET + NUM_BUFFER_PARTITIONS)


#define PREDICATELOCK_MANAGER_LWLOCK_OFFSET \

(NUM_INDIVIDUAL_LWLOCKS + NUM_LOCK_PARTITIONS)


#define NUM_FIXED_LWLOCKS \

(PREDICATELOCK_MANAGER_LWLOCK_OFFSET + NUM_PREDICATELOCK_PARTITIONS)


In this PREDICATELOCK_MANAGER_LWLOCK_OFFSET

should consider NUM_BUFFER_PARTITIONS which means

it should be:


#define PREDICATELOCK_MANAGER_LWLOCK_OFFSET \

(LOCK_MANAGER_LWLOCK_OFFSET + NUM_LOCK_PARTITIONS)


If we don't consider buffer partitions in above calculation,
then the total shared memory allocated for fixed locks will
be wrong and can cause problems.


I have noticed this during my work on scaling shared
buffers where if I increase NUM_BUFFER_PARTITIONS,
it leads to hang for tpc-b test and as per my analysis
the reason is above calculation. 

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: Minmax indexes
Next
From: Petr Jelinek
Date:
Subject: Re: Atomics hardware support table & supported architectures