pgsql: Make the lock hash tables fixed-sized - Mailing list pgsql-committers

From Heikki Linnakangas
Subject pgsql: Make the lock hash tables fixed-sized
Date
Msg-id E1w8iNH-002maU-18@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Make the lock hash tables fixed-sized

This prevents the LOCK table from "stealing" space that was originally
calculated for the PROLOCK table, and vice versa. That was weirdly
indeterministic so that if you e.g. took a lot of locks consuming all
the available shared memory for the LOCK table, subsequent
transactions that needed the more space for the PROCLOCK table would
fail, but if you restarted the system then the space would be
available for PROCLOCK again. Better to be strict and predictable,
even though that means that in many cases you can acquire far fewer
locks than before.

This also prevents the lock hash tables from using up the
general-purpose 100 kB reserve we set aside for "stuff that's too
small to bother estimating" in CalculateShmemSize(). We are pretty
good at accounting for everything nowadays, so we could probably make
that reservation smaller, but I'll leave that for another commit.

Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com>
Discussion: https://www.postgresql.org/message-id/e07be2ba-856b-4ff5-8313-8b58b6b4e4d0@iki.fi

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/e1ad034809a4628b995ae458d0d56744ca3b5ff3

Modified Files
--------------
src/backend/storage/lmgr/lock.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)


pgsql-committers by date:

Previous
From: Amit Langote
Date:
Subject: Re: pgsql: Optimize fast-path FK checks with batched index probes
Next
From: Nathan Bossart
Date:
Subject: pgsql: Refactor relation_needs_vacanalyze().