Re: Very strange postgresql behaviour

Tom Lane wrote:
> Arnau <arnaulist@andromeiberica.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:

   I don't know, we have discovered those two rows but I'm not sure if
there are more. Is there any way to check it?

>
> 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.

   My intention was not spam mulitple lists, the problem was that I was
not sure where to post this question.


--
Arnau