What does "tuple concurrently updated" mean?
Hi
During a batch load of records (using COPY) I got the following
postgres error today "tuple concurrently updated".
What could have caused this?
The only two occurences of the message in the source is in
the functions simple_head_delete and simple_heap_update
in src/backend/access/heap/heapam.c
greetings, Florian Pflug
"Florian G. Pflug" <fgp@phlo.org> writes:
During a batch load of records (using COPY) I got the following
postgres error today "tuple concurrently updated".
I don't think plain COPY could have produced that, since it only inserts
tuples. Tell us about triggers and foreign keys on this table?
regards, tom lane
Tom Lane wrote:
"Florian G. Pflug" <fgp@phlo.org> writes:
During a batch load of records (using COPY) I got the following
postgres error today "tuple concurrently updated".I don't think plain COPY could have produced that, since it only inserts
tuples. Tell us about triggers and foreign keys on this table?
Sorry, I was confused. The error didn't actually happen while copying,
it happened while "analyze"-ing the tables after the import. I
confused this, because the analyze is started from our import-script,
and the log just showed the error-message postgres gave ;-)
So - does "tuple concurrently updated" make sense for "analyze"?
greetings, Florian Pflug
"Florian G. Pflug" <fgp@phlo.org> writes:
So - does "tuple concurrently updated" make sense for "analyze"?
Yeah, it's entirely possible, if you have a background process that
might issue analyzes too (do you use autovacuum?). The error comes when
two sessions concurrently try to update the same row in pg_statistic.
I've looked at preventing it, but the cure seems worse than the disease
--- we don't really want ANALYZE to take any strong locks on the table,
and in any case all you are losing is presumably-near-duplicate stats
from one session or the other.regards, tom lane
Tom Lane wrote:
"Florian G. Pflug" <fgp@phlo.org> writes:
So - does "tuple concurrently updated" make sense for "analyze"?
Yeah, it's entirely possible, if you have a background process that might issue analyzes too (do you use autovacuum?). The error comes when two sessions concurrently try to update the same row in pg_statistic. I've looked at preventing it, but the cure seems worse than the disease --- we don't really want ANALYZE to take any strong locks on the table, and in any case all you are losing is presumably-near-duplicate stats from one session or the other.
Hm... could this be turned into a warning then? I'll fix this
by ignoring db-errors when issuing analyze, but I belive this
will bite more people...
Anyway, thanks for your fast reply - I'll sleep much better,
now that I know the cause for this ;-)
greetings, Florian Pflug