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