Thread: 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