Skip site navigation (1) Skip section navigation (2)

max_locks_per_transactions ...

From: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
To: pgsql-hackers(at)postgresql(dot)org, Zoltan Boszormenyi <zb(at)cybertec(dot)at>
Subject: max_locks_per_transactions ...
Date: 2007-02-01 08:15:42
Message-ID: 45C1A1AE.1070307@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackers
Right now max_locks_per_transactions defines the average number of locks 
taken by a transaction. thus, shared memory is limited to 
max_locks_per_transaction * (max_connections + max_prepared_transactions).
this is basically perfect. however, recently we have seen a couple of 
people having trouble with this. partitioned tables are becoming more 
and more popular so it is very likely that a single transaction can eat 
up a great deal of shared memory. some people having a lot of data 
create daily tables. if done for 3 years we already lost 1000 locks per 
inheritance-structure.

i wonder if it would make sense to split max_locks_per_transaction into 
two variables: max_locks (global size) and max_transaction_locks (local 
size). if set properly this would prevent "good" short running 
transactions from running out of shared memory when some "evil" long 
running transactions start to suck up shared memory.

if people find this useful we would glady implement this new feature for 
8.3.

    many thanks,

       hans

-- 
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at


Responses

pgsql-hackers by date

Next:From: Zeugswetter Andreas ADI SDDate: 2007-02-01 09:12:07
Subject: Re: "May", "can", "might"
Previous:From: Peter EisentrautDate: 2007-02-01 07:42:47
Subject: Re: "May", "can", "might"

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group