andy <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> andy <[EMAIL PROTECTED]> writes: >>> So I'm ok, but I tried it again, by dropping the database and re-running >>> both scripts and got the same error again. So thought I'd offer a test >>> case if there was interest. >> >> Absolutely. I've seen just enough of these reports to make me think >> there's an underlying bug.
> Here are some urls: ... Doh ... I think the critical bit is here: autovacuum = on # enable autovacuum subprocess? The problem is that ANALYZE takes only AccessShareLock on a table, so it's entirely possible for two backends to try to ANALYZE the same table concurrently, and in particular for autovacuum to try to do so while your foreground VACUUM ANALYZE is running. That leads to concurrent insertion attempts into pg_statistic for the same key. 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? 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