Re: ERROR : 'tuple concurrently updated' - Mailing list pgsql-hackers

From Cédric Villemain
Subject Re: ERROR : 'tuple concurrently updated'
Date
Msg-id 10579613.XsFTFFkFdK@obelix
Whole thread Raw
In response to Re: ERROR : 'tuple concurrently updated'  (Stéphan BEUZE <stephan.beuze@douane.finances.gouv.fr>)
Responses Re: ERROR : 'tuple concurrently updated'
List pgsql-hackers
>  > What PostgreSQL version is this?
>
> I'm using "Postgresql 9.2.4, compiled by Visual C++ build 1600,
> 64-bit"
>  > Are there any triggers on any of these tables?
>
> There are no triggers.
>
>  > Any noteworthy extensions installed?
>
> Here is the results returned by "select * from
> pg_available_extensions"

Those extensions are installed in the system, so you can install them in
PostgreSQL.
You may also have contrib run by servers without being pure extension.

So the question is about used extensions or contrib. (it can be loaded
by server, or in a session with LOAD, it can be auto-explain,
pg_stat_statement, ....).

> > There are actually two places where that error can happen:
> > simple_heap_update and simple_heap_delete.  If you set the error
> > verbosity to verbose, you should be able to see which function is at
> > fault.  The thing is, I don't see anything in that query which would
> > update or delete any tuples, so there must be more to the story.  If
> > you have the ability to build from source, you could try setting a
> > long sleep just before that error is thrown.  Then run your test
> > case
> > until it hangs at that spot and get a stack backtrace.  But that may
> > be more troubleshooting than you want to get into.


--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Turning recovery.conf into GUCs
Next
From: Robert Haas
Date:
Subject: Re: logical changeset generation v6.4