Tom Lane wrote:
> 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:
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?
> 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.
In response to
pgsql-admin by date
|Next:||From: Tom Lane||Date: 2007-01-29 19:02:46|
|Subject: Re: Very strange postgresql behaviour |
|Previous:||From: Tom Dong||Date: 2007-01-29 17:01:26|
|Subject: Postgres encyrption export|