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