From: | tgl(at)postgresql(dot)org (Tom Lane) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Change ANALYZE to take ShareUpdateExclusiveLock not |
Date: | 2006-09-17 22:50:31 |
Message-ID: | 20060917225031.B9A989FA087@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Log Message:
-----------
Change ANALYZE to take ShareUpdateExclusiveLock not AccessShareLock on
the table being analyzed. This prevents two ANALYZEs from running
concurrently on the same table and possibly suffering concurrent-update
failures while trying to store their results into pg_statistic. The
downside is that a database-wide ANALYZE executed within a transaction
block will hold ShareUpdateExclusiveLock on many tables simultaneously,
which could lead to concurrency issues or even deadlock against another
such ANALYZE. However, this seems a corner case of less importance
than getting unexpected errors from a foreground ANALYZE when autovacuum
elects to analyze the same table concurrently. Per discussion.
Modified Files:
--------------
pgsql/doc/src/sgml:
mvcc.sgml (r2.60 -> r2.61)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/mvcc.sgml.diff?r1=2.60&r2=2.61)
pgsql/src/backend/commands:
analyze.c (r1.97 -> r1.98)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/analyze.c.diff?r1=1.97&r2=1.98)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-18 00:52:15 | pgsql: Fix CREATE TABLE ... |
Previous Message | Tom Lane | 2006-09-17 22:16:23 | pgsql: Marginal cleanup in arrangements for ensuring StrategyHintVacuum |