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 |
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 |