OSDN Git Service

Now that we allow ANALYZE to run inside a transaction block, the locks
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 11 Aug 2002 00:08:48 +0000 (00:08 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 11 Aug 2002 00:08:48 +0000 (00:08 +0000)
commit2e10863bf52797a7a285271677e3f2c35a376f20
tree679e61f03d46e55c3b8d41a6fd6fd43002f04d13
parent5c3102d6d1fe85c68759480e88703d49780e1783
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'.
src/backend/commands/analyze.c