Re: BUG #17985: Inconsistent results of SELECT comparing two CASE WHEN clause

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: zuming(dot)jiang(at)inf(dot)ethz(dot)ch
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17985: Inconsistent results of SELECT comparing two CASE WHEN clause
Date: 2023-06-20 18:40:41
Message-ID: 3564217.1687286441@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> My fuzzer finds a correctness bug in Postgres, which makes Postgres return
> inconsistent results.

Huh. This is a very ancient bug, dating seemingly to commit d24d75ff1.
When rescanning a hash join, we'll skip rebuilding the hash table if
the inner subplan contains no updated Param values. However, the
inner hash key expressions can themselves contain Param references,
which evidently are not caught by that test. A change in the value
of such a Param necessitates rebuilding the hash table, and this
example shows that we're not doing that.

One way to fix it is as attached. I wonder though if this isn't
telling us that there's a bug in the planner's assignment of
allParams bits for Hash nodes. The dangerous Param is present
in the Hash node's hashkeys field, so why isn't the existing
chgParam test adequate?

regards, tom lane

Attachment Content-Type Size
quick-fix-for-bug-17985.patch text/x-diff 5.9 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2023-06-20 20:54:39 BUG #17986: Inconsistent results of SELECT affected by btree index
Previous Message David G. Johnston 2023-06-20 16:34:22 Re: BUG #17984: Service stopped and cannot restart