vacuumdb error: tuple concurrently updated

Lists: pgsql-bugs
From: Harald Krake <harald(at)krake(dot)de>
To: pgsql-bugs(at)postgresql(dot)org
Subject: vacuumdb error: tuple concurrently updated
Date: 2002-12-25 16:07:21
Message-ID: aucl3k$2v4l$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

while running a "vacuumdb -z" I got the following error message:

ERROR: simple_heap_update: tuple concurrently updated
vacuumdb: vacuum jartifice failed

Is this something to worry about? Especially data corruption?
(postgres 7.3 / linux)

regards,
harald.


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Harald Krake <harald(at)krake(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: vacuumdb error: tuple concurrently updated
Date: 2002-12-26 17:09:03
Message-ID: 1717.1040922543@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

Harald Krake <harald(at)krake(dot)de> writes:
> while running a "vacuumdb -z" I got the following error message:
> ERROR: simple_heap_update: tuple concurrently updated
> vacuumdb: vacuum jartifice failed

Is it likely that someone else was doing the same thing in another
session? This failure is known to occur if two backends concurrently
ANALYZE the same table --- the second one to try to update the
pg_statistics row fails because of the concurrent write. It's quite
harmless, except for preventing the rest of the VACUUM command from
completing.

regards, tom lane


From: Harald Krake <harald(at)krake(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: vacuumdb error: tuple concurrently updated
Date: 2002-12-26 19:37:46
Message-ID: 200212262037.46122.harald@krake.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs

On Thursday 26 December 2002 06:09 pm, Tom Lane wrote:
> Is it likely that someone else was doing the same thing in another
> session?

no ANALYZE in parallel but another client constantly running transactions
(over 6 tables with approx. 20 - 100 updates/inserts per transaction).
The postgres client generates a permanent cpu load of 80-90% for days.
To keep the transaction rate at a reasonable level we run a "vacuumdb -z"
via a shell script in a while-loop with a "sleep 3600" in between.
I suspect the vacuumdb returns to the shell when the ANALYZE has finished,
so it should be impossible that two ANALYZE were running at the same time (?)

As long as it's harmless, we can live with that.

Btw.: is there a tool to check the consistency of a postgres database?

regards,
harald.