Re: Very strange postgresql behaviour

[Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>]

Arnau <arnaulist(at)andromeiberica(dot)com> writes:
>    I have postgresql 7.4.2 running on debian and I have the oddest 
> postgresql behaviour I've ever seen.

Is this specific to these two rows?  If so it might be a case of this
bug, which was repaired in 7.4.13:

http://archives.postgresql.org/pgsql-general/2006-05/msg00756.php
http://archives.postgresql.org/pgsql-committers/2006-05/msg00174.php

2006-05-19 12:31  tgl

	* src/backend/executor/nodeIndexscan.c (REL7_4_STABLE): Fix nasty
	bug in nodeIndexscan.c's detection of duplicate tuples during a
	multiple (OR'ed) indexscan.  It was checking for duplicate
	tuple->t_data->t_ctid, when what it should be checking is
	tuple->t_self.	The trouble situation occurs when a live tuple has
	t_ctid not pointing to itself, which can happen if an attempted
	UPDATE was rolled back.  After a VACUUM, an unrelated tuple could
	be installed where the failed update tuple was, leading to one live
	tuple's t_ctid pointing to an unrelated tuple.	If one of these
	tuples is fetched by an earlier OR'ed indexscan and the other by a
	later indexscan, nodeIndexscan.c would incorrectly ignore the
	second tuple.  The bug exists in all 7.4.* and 8.0.* versions, but
	not in earlier or later branches because this code was only used in
	those releases.  Per trouble report from Rafael Martinez Guerrero.

REINDEX wouldn't fix this, although a table dump and reload would.

			regards, tom lane

PS: please don't spam multiple lists with the same question.