| From: | tgl(at)postgresql(dot)org (Tom Lane) |
|---|---|
| To: | pgsql-committers(at)postgresql(dot)org |
| Subject: | pgsql-server/src/backend/commands analyze.c |
| Date: | 2002-08-11 00:08:48 |
| Message-ID: | 20020811000848.5CED447580F@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl(at)postgresql(dot)org 02/08/10 20:08:48
Modified files:
src/backend/commands: analyze.c
Log message:
Now that we allow ANALYZE to run inside a transaction block, the locks
it takes could be held for quite awhile after the analyze step completes.
Rethink locking of pg_statistic in light of this fact. The original
scheme took an exclusive lock on pg_statistic, which was okay when the
lock could be expected to be released shortly, but that doesn't hold
anymore. Back off to a normal writer's lock (RowExclusiveLock). This
allows concurrent ANALYZE of nonoverlapping sets of tables, at the price
that concurrent ANALYZEs of the same table may fail with 'tuple
concurrently updated'.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-08-11 00:18:59 | pgsql-server/src/backend/utils/error format.c |
| Previous Message | Jeroen | 2002-08-10 23:29:11 | interfaces/libpqxx Makefile.am include/pqxx/co ... |