aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeHashjoin.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2015-11-05 18:15:48 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2015-11-05 18:15:48 -0500
commit4d867458fce3743adc95ad6513c9d2dea87cd7f4 (patch)
tree4d89acc0ac1b5ad5f568f73a979e743bcebd5b6b /src/backend/executor/nodeHashjoin.c
parentc98605cc47fe42fac5f685d611db2a0c1afa2fcf (diff)
downloadpostgresql-4d867458fce3743adc95ad6513c9d2dea87cd7f4.tar.gz
postgresql-4d867458fce3743adc95ad6513c9d2dea87cd7f4.zip
Fix erroneous hash calculations in gin_extract_jsonb_path().
The jsonb_path_ops code calculated hash values inconsistently in some cases involving nested arrays and objects. This would result in queries possibly not finding entries that they should find, when using a jsonb_path_ops GIN index for the search. The problem cases involve JSONB values that contain both scalars and sub-objects at the same nesting level, for example an array containing both scalars and sub-arrays. To fix, reset the current stack->hash after processing each value or sub-object, not before; and don't try to be cute about the outermost level's initial hash. Correcting this means that existing jsonb_path_ops indexes may now be inconsistent with the new hash calculation code. The symptom is the same --- searches not finding entries they should find --- but the specific rows affected are likely to be different. Users will need to REINDEX jsonb_path_ops indexes to make sure that all searches work as expected. Per bug #13756 from Daniel Cheng. Back-patch to 9.4 where the faulty logic was introduced.
Diffstat (limited to 'src/backend/executor/nodeHashjoin.c')
0 files changed, 0 insertions, 0 deletions