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.