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


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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to