Re: [GENERAL] Weird ..... (a=1 or a=2) <> (a=2 or a=1)
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] Weird ..... (a=1 or a=2) <> (a=2 or a=1) |
Дата | |
Msg-id | 29491.1148052855@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [GENERAL] Weird ..... (a=1 or a=2) <> (a=2 or a=1)
Re: [GENERAL] Weird ..... (a=1 or a=2) <> (a=2 or a=1) |
Список | 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
В списке pgsql-hackers по дате отправления: