Thread: Required locks for ANALYZE

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/9.5/sql-select.html
Description:

The below document says that the ANALYZE statement requires a read lock.
https://www.postgresql.org/docs/current/sql-analyze.html
-----
ANALYZE requires only a read lock on the target table, so it can run in
parallel with other activity on the table.
-----

But it is too vague as there is no such table level lock. In addition, the
document explains the SHARE UPDATE EXCLUSIVE table lock obtained by
ANALYZE.
https://www.postgresql.org/docs/current/explicit-locking.html
-----
SHARE UPDATE EXCLUSIVE
Conflicts with the SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE,
EXCLUSIVE, and ACCESS EXCLUSIVE lock modes. This mode protects a table
against concurrent schema changes and VACUUM runs.

Acquired by VACUUM (without FULL), ANALYZE, CREATE INDEX CONCURRENTLY,
CREATE STATISTICS and ALTER TABLE VALIDATE and other ALTER TABLE variants
(for full details see ALTER TABLE).
-----

Therefore, in my opinion, the below paragraph should be amended as below.

* Before
-----
ANALYZE requires only a read lock on the target table, so it can run in
parallel with other activity on the table.
-----

* After
-----
ANALYZE requires only a SHARE UPDATE EXCLUSIVE lock on the target table, so
it can run in parallel with queries requiring ACCESS SHARE/ROW SHARE/ROW
EXCLUSIVE locks such as SELECT, UPDATE, DELETE, INSERT on the table.
-----

PG Doc comments form <noreply@postgresql.org> writes:
> Therefore, in my opinion, the below paragraph should be amended as below.

> * Before
> -----
> ANALYZE requires only a read lock on the target table, so it can run in
> parallel with other activity on the table.
> -----

> * After
> -----
> ANALYZE requires only a SHARE UPDATE EXCLUSIVE lock on the target table, so
> it can run in parallel with queries requiring ACCESS SHARE/ROW SHARE/ROW
> EXCLUSIVE locks such as SELECT, UPDATE, DELETE, INSERT on the table.
> -----

This does not really seem like an improvement.  The second formulation is
pedantically correct, but also unintelligible.

Maybe we could make it say "run in parallel with non-DDL activity" ?

            regards, tom lane

On Mon, Sep 30, 2019 at 04:46:56PM +0900, Aramaki Zyake wrote:
> Hi,
> 
> I’m terribly sorry for the delay of response.
> 
>  
> 
> >This does not really seem like an improvement.  The second formulation is
> 
> >pedantically correct, but also unintelligible.
> 
> > 
> 
> > Maybe we could make it say "run in parallel with non-DDL activity" ?
> 
>  
> 
> I completely agree with you, therefore, I amended it as follows.
> 
> ----
> 
> ANALYZE requires only a read lock on the target table, so it can run in
> 
> parallel with non-DDL activity on the table.

I know this report is four years old, but attached patch applied to
master.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.