andy <andy@squeakycode.net> writes:
> Tom Lane wrote:
>> andy <andy@squeakycode.net> 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
