public inbox for [email protected]  

help / color / mirror / Atom feed

From: Josh Berkus <[email protected]>
To: [email protected]
Subject: Comment on max_locks_per_transaction
Date: Fri, 15 Jun 2012 11:05:30 -0700
Message-ID: <[email protected]> (raw)

Folks,

Way it is now:

===============

max_locks_per_transaction (integer)

    The shared lock table tracks locks on max_locks_per_transaction *
(max_connections + max_prepared_transactions) objects (e.g., tables);
hence, no more than this many distinct objects can be locked at any one
time. This parameter controls the average number of object locks
allocated for each transaction; individual transactions can lock more
objects as long as the locks of all transactions fit in the lock table.
This is not the number of rows that can be locked; that value is
unlimited. The default, 64, has historically proven sufficient, but you
might need to raise this value if you have clients that touch many
different tables in a single transaction. This parameter can only be set
at server start.

    Increasing this parameter might cause PostgreSQL to request more
System V shared memory than your operating system's default
configuration allows. See Section 17.4.1 for information on how to
adjust those parameters, if necessary.

    When running a standby server, you must set this parameter to the
same or higher value than on the master server. Otherwise, queries will
not be allowed in the standby server.

================

The way it should be:

max_locks_per_transaction (integer)

    The shared lock table tracks locks on max_locks_per_transaction *
(max_connections + max_prepared_transactions) objects (e.g., tables);
hence, no more than this many distinct objects can be locked at any one
time. This parameter controls the average number of object locks
allocated for each transaction; individual transactions can lock more
objects as long as the locks of all transactions fit in the lock table.
This is not the number of rows that can be locked; that value is
unlimited. This parameter can only be set at server start.

The default, 64, has historically proven sufficient for most databases,
but you might need to raise this value if you have clients that touch
many different tables in a single transaction.  Databases with several
tables with many partitions each can require raising this setting.  The
PostgreSQL activity log will contain a fairly clear error message
suggesting raising max_locks_per_transaction if needed.

    Increasing this parameter might cause PostgreSQL to request more
System V shared memory than your operating system's default
configuration allows. See Section 17.4.1 for information on how to
adjust those parameters, if necessary.

    When running a standby server, you must set this parameter to the
same or higher value than on the master server. Otherwise, queries will
not be allowed in the standby server.


-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

view thread (10+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected]
  Subject: Re: Comment on max_locks_per_transaction
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox