Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-sql-owner+archive@lists.postgresql.org>)
	id 1jUWUX-0000Gg-G3
	for pgsql-sql@arkaria.postgresql.org; Fri, 01 May 2020 14:18:13 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-sql-owner+archive@lists.postgresql.org>)
	id 1jUWUW-0004bn-C5
	for pgsql-sql@arkaria.postgresql.org; Fri, 01 May 2020 14:18:12 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1jUWUW-0004bg-5n
	for pgsql-sql@lists.postgresql.org; Fri, 01 May 2020 14:18:12 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1jUWUT-00079W-VM
	for pgsql-sql@postgresql.org; Fri, 01 May 2020 14:18:11 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 041EI8Ll017876;
	Fri, 1 May 2020 10:18:08 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Viral Shah <viralshah009@gmail.com>
cc: Rene Romero Benavides <rene.romero.b@gmail.com>, pgsql-sql@postgresql.org
Subject: Re: pg_dump fails when a table is in ACCESS SHARE MODE
In-reply-to: 
 <CAEVFvu3N4sANuPzWuvN-UmPP--mphPM3MiXMtQhgH+WctSjq5A@mail.gmail.com>
References: 
 <CAEVFvu0aY4qgxVtMJvPTqty0pmL-jqsbsY9DkmA8REDbQtwKcw@mail.gmail.com>
 <CANaGW086GF5qioi8=R0p6-Hh=Y-p4gsxr4FCYi9eHC5TzCgr+A@mail.gmail.com>
 <CAEVFvu3UgFD919fW+XdfFMUq_LofD_1EhACd_CL6rt6eNqGg0w@mail.gmail.com>
 <CANaGW0-XmCzJuME3EqQjO=g=hWv45v345pE8F-kVMygW2fBTJA@mail.gmail.com>
 <CANaGW0_cQHOBQ9fLKwc8qEObBvpP_Ocy=mNuzF0h9dfWfxVevw@mail.gmail.com>
 <CAEVFvu3gDgSOayvOxHXe7e0=6w_6WhQk4m9S=gz5iHvpT0DmDg@mail.gmail.com>
 <CANaGW0_Rps9JtszHMei3seN_kSt_WQhNY6Ch=2qTPuM_B1MB+Q@mail.gmail.com>
 <CAEVFvu3N4sANuPzWuvN-UmPP--mphPM3MiXMtQhgH+WctSjq5A@mail.gmail.com>
Comments: In-reply-to Viral Shah <viralshah009@gmail.com>
	message dated "Fri, 01 May 2020 09:53:58 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17874.1588342688.1@sss.pgh.pa.us>
Date: Fri, 01 May 2020 10:18:08 -0400
Message-ID: <17875.1588342688@sss.pgh.pa.us>
List-Id: <pgsql-sql.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-sql@lists.postgresql.org>
List-Owner: <mailto:pgsql-sql-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-sql>
Precedence: bulk

Viral Shah <viralshah009@gmail.com> writes:
> Per the postgres documentation,
> *max_locks_per_transaction * (max_connections + max_prepared_transactions)*
> this formula determines the max no of allowed objects that can be locked on
> the database. Currently my database has the following values:
> *max_locks_per_transaction = 64 (default)*
> *max_connections = 100*
> *max_prepared_transactions = 0*
> Using this value in the above formula tells that our database or rather
> postgres server can/should handle *6400* locked objects at a time.

Right.

> What is surprising is why Postgres complains of insufficient locks per
> transaction if only 10 processes (parallel jobs in pg_dump) are running on
> the database while taking the dump.

They're taking more than 6400 locks, evidently.   How many tables are
in your database?  Have you tried looking into pg_locks while the dump
is running?

			regards, tom lane