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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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