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: | Raw Message | Whole Thread | 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 ... |