calculation for NUM_FIXED_LWLOCKS

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

Responses

Browse pgsql-hackers by date

  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