From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bindra <11bindra11@gmail.com>
cc: pgsql-admin@lists.postgresql.org
Subject: Re: pg_dump blocks insert update on table
In-reply-to: 
 <CABeMV7Pq07Ebe8Guh50qna=Om6mLa6Q6MJC_odagRTfe7WPW-Q@mail.gmail.com>
References: 
 <CABeMV7Pq07Ebe8Guh50qna=Om6mLa6Q6MJC_odagRTfe7WPW-Q@mail.gmail.com>
Comments: In-reply-to Bindra <11bindra11@gmail.com>
	message dated "Thu, 29 Feb 2024 20:36:40 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2711363.1709226898.1@sss.pgh.pa.us>
Date: Thu, 29 Feb 2024 12:14:58 -0500
Message-ID: <2711364.1709226898@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2711364.1709226898%40sss.pgh.pa.us>
Precedence: bulk

Bindra <11bindra11@gmail.com> writes:
> We are using PostgreSQL 11.17

You realize that 11.x is out of support, right?

> While doing pg_dumpall, it blocks insert/update on some table where copy
> statemnets is executed.

pg_dump only takes AccessShareLock on tables it dumps.  That does not
block inserts or updates.  What may be happening is that you have some
third process that is trying to take an exclusive lock on the table.
It will queue up behind pg_dump's nonexclusive lock, and then other
operations such as insert/update will block behind it.  This is just
speculation since you've provided zero detail, but that's what I'd
look for.  The pg_locks view could help you identify the culprit.

			regards, tom lane