Re: attempted to lock invisible tuple - PG 8.4.1

From: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
To: Stuart Bishop <stuart(at)stuartbishop(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: attempted to lock invisible tuple - PG 8.4.1
Date: 2009-10-05 09:22:31
Message-ID: DE2EBE69-43DD-4121-8382-F299B4C398CA@solfertje.student.utwente.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 5 Oct 2009, at 8:58, Stuart Bishop wrote:

> I'm running our products test suite against PostgreSQL 8.4.1. The test
> suite runs fine against 8.3.7.
>
> With 8.4.1, some of our tests are failing with the exception
> 'attempted to lock invisible tuple'. The failures are repeatable -
> they crash every time at the same point. They crash no matter if they
> are being run in isolation or as part of the larger test suite.
>
> Anyone know what we could be doing that triggers that? Looking at our
> statement logs we don't seem to be doing anything unusual. The failing
> tests I've checked are running under SERIALIZABLE isolation level, and
> the database will have been recreated a few instants ago using
> 'createdb --template test_template_db'.

A similar issue was discussed just recently here: http://archives.postgresql.org/pgsql-general/2009-09/msg01219.php

That issue involved cursors though (and a serializable isolation
level, but you have that). Do you have any triggers that use cursors
on the table that the update fails for?

> One of the statement logs is at http://paste.ubuntu.com/285983/ - I
> can't see anything unusual
> going on but it might help diagnose the problem.

Alban Hertroys

--
Screwing up is the best way to attach something to the ceiling.

!DSPAM:737,4ac9bad911688389419940!

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thom Brown 2009-10-05 09:48:25 Re: Postgres won't start. Nothing in the log.
Previous Message Markus Wollny 2009-10-05 08:13:40 Re: Postgres won't start. Nothing in the log.