From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | calculation for NUM_FIXED_LWLOCKS |
Date: | 2014-06-19 10:19:58 |
Message-ID: | CAA4eK1JQrxZ15GgsHUFe1Yx7k5-9+k9qqDR=rVkM1DOfKox1pw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2014-06-19 11:33:03 | Re: Atomics hardware support table & supported architectures |
Previous Message | Vik Fearing | 2014-06-19 09:41:52 | Re: Minmax indexes |