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. +
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>
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
