Change ANALYZE to take ShareUpdateExclusiveLock not AccessShareLock on
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 17 Sep 2006 22:50:31 +0000 (22:50 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 17 Sep 2006 22:50:31 +0000 (22:50 +0000)
commitc33ccd4a7302580ede199a01cb520d5bfc1db839
tree28e4e2beabcda8c200e89f32a23049337a71d846
parent20f0f103cc2259f2cf8df15d0066c43abe71b64b
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.
doc/src/sgml/mvcc.sgml
src/backend/commands/analyze.c