public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Josh Berkus <[email protected]>
Cc: [email protected]
Subject: Re: Comment on max_locks_per_transaction
Date: Thu, 30 Aug 2012 16:56:38 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
I have applied the attached patch to document this issue.
---------------------------------------------------------------------------
On Fri, Jun 15, 2012 at 11:05:30AM -0700, Josh Berkus wrote:
> 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
>
> --
> Sent via pgsql-docs mailing list ([email protected])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-docs
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
[text/x-diff] locks.diff (1.1K, 2-locks.diff)
download | inline diff:
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
new file mode 100644
index d5fa94e..ade9f79
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*************** dynamic_library_path = 'C:\tools\postgre
*** 5550,5558 ****
fit in the lock table. This is <emphasis>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.
</para>
<para>
--- 5550,5558 ----
fit in the lock table. This is <emphasis>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 queries that touch many different
! tables in a single transaction, e.g. query of a parent table with
! many children. This parameter can only be set at server start.
</para>
<para>
view thread (10+ messages)
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], [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