Re: Comment on max_locks_per_transaction

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-docs(at)postgreSQL(dot)org
Subject: Re: Comment on max_locks_per_transaction
Date: 2012-08-30 20:56:38
Message-ID: 20120830205638.GA8753@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs


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 (pgsql-docs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-docs

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Attachment Content-Type Size
locks.diff text/x-diff 1.1 KB

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Bruce Momjian 2012-08-30 21:58:48 Re: Out of date advice about SIGTERM'ing backends
Previous Message Bruce Momjian 2012-08-30 18:45:39 Re: vacuum monitoring in the doc