diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2006-09-17 22:50:31 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2006-09-17 22:50:31 +0000 |
| commit | da7540b9d17c09c3b2e49a7580e5f42dcc4a4bcd (patch) | |
| tree | 9c1d30fc2f7bf47ee4355f52bb604872b9aec803 /src/backend/parser/analyze.c | |
| parent | 2e5e856f6b4f4e7445ec4b14fc4504469f6f4f54 (diff) | |
| download | postgresql-da7540b9d17c09c3b2e49a7580e5f42dcc4a4bcd.tar.gz postgresql-da7540b9d17c09c3b2e49a7580e5f42dcc4a4bcd.zip | |
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.
Diffstat (limited to 'src/backend/parser/analyze.c')
0 files changed, 0 insertions, 0 deletions