"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> One possible fix today would be to make ANALYZE take
>> ShareUpdateExclusive lock instead, thus ensuring there is only one
>> ANALYZE at a time on a table.
> Why not an internal lock that people don't see?
We could add another LockTagType just for ANALYZE, but that seems like
rather a lot of infrastructure to support an extremely narrow corner
case, namely two people doing database-wide ANALYZE at the same time
inside transaction blocks. (If they do it outside a transaction block
then the ANALYZE is divided into multiple xacts and so doesn't try to
hold locks on multiple tables concurrently. autovacuum won't try to do
that either.) There's no such animal as "an internal lock people don't
see" --- if we went this way it'd propagate into user-visible entries in
pg_locks, for example.
ISTM it should be sufficient to use ShareUpdateExclusiveLock. The only
real argument I can see against it is you couldn't ANALYZE and VACUUM
a table at the same time ... but that's probably a bad idea anyway,
especially if we extend ANALYZE to estimate dead-tuple statistics.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
