This behavior dates from a time when there was no good alternative.
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. However I'm a bit concerned by the
possibility that ANALYZE-inside-a-transaction could accumulate a
whole bunch of such locks in a random order, leading at least to
a risk of deadlocks against other ANALYZEs. (We have to hold the
lock till commit, else we aren't fixing the problem.) Do we need a
specialized lock type just for ANALYZE? Would sorting the target
list of rel OIDs be enough? Perhaps it's not worth worrying about?
Why not an internal lock that people don't see? The behavior would the
following:
conn1: analyze foo;
conn2: analyze foo;
ERROR: analyze already running on foo
conn1: analyze foo;
conn2: analyze;
NOTICE: analyze full started, analyze running on foo, skipping foo
Sincerely,
Joshua D. Drake
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
