Обсуждение: 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