From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Rafael Martinez, Guerrero" <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [GENERAL] Weird ..... (a=1 or a=2) <> (a=2 or a=1) |
Date: | 2006-05-19 15:34:15 |
Message-ID: | 29491.1148052855@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Many thanks for allowing me to trace through your problem case.
It's a real Postgres bug, and a nasty one. The problem is a thinko in
nodeIndexscan.c's code that tests whether the same tuple has already
been emitted in a previous OR'd scan: it is looking for a match on
tuple->t_data->t_ctid, when what it should really be looking at is
tuple->t_self. What I find is that the indexscan for status == open
is returning TID (880,5), which has XMAX_INVALID and a t_ctid pointing
at (880,18). (This is perfectly normal, it just indicates that
somebody tried to update the row but the updating transaction rolled
back, and the updated version at 880,18 was later recycled by VACUUM.)
So this causes a bogus rejection when TID (880,18) is scanned during the
second indexscan.
This only affects the 7.4 and 8.0 branches, because earlier and later
versions of Postgres don't use this technique for detecting duplicates.
But it's surprising we didn't find it before.
Patches will appear in next week's releases. Thanks again!
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Reid Thompson | 2006-05-19 15:36:16 | background writer process (PID 1400) exited with exit code 0 -- repeatedly && incomplete startup packet |
Previous Message | Csaba Nagy | 2006-05-19 15:32:11 | Re: allow LIMIT in UPDATE and DELETE |
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2006-05-19 15:36:21 | Re: [HACKERS] Toward A Positive Marketing Approach. |
Previous Message | Joshua Kramer | 2006-05-19 15:29:43 | Re: [HACKERS] Toward A Positive Marketing Approach. |