]> granicus.if.org Git - postgresql/commit
Fix hstore hash function for empty hstores upgraded from 8.4.
authorAndrew Gierth <rhodiumtoad@postgresql.org>
Sat, 24 Nov 2018 09:59:49 +0000 (09:59 +0000)
committerAndrew Gierth <rhodiumtoad@postgresql.org>
Sat, 24 Nov 2018 21:17:09 +0000 (21:17 +0000)
commit239abfff12a41a0611d24e2c7b67895a7359e6bf
tree9e171732219855a9811c8eae2582d48f28c0988a
parent1f99d0867020377defa251cc61943f3d4239e9eb
Fix hstore hash function for empty hstores upgraded from 8.4.

Hstore data generated on pg 8.4 and pg_upgraded to current versions
remains in its original on-disk format unless modified. The same goes
for values generated by the addon hstore-new module on pre-9.0
versions. (The hstoreUpgrade function converts old values on the fly
when read in, but the on-disk value is not modified by this.)

Since old-format empty hstores (and hstore-new hstores) have
representations compatible with the new format, hstoreUpgrade thought
it could get away without modifying such values; but this breaks
hstore_hash (and the new hstore_hash_extended) which assumes
bit-perfect matching between semantically identical hstore values.
Only one bit actually differs (the "new version" flag in the count
field) but that of course is enough to break the hash.

Fix by making hstoreUpgrade unconditionally convert all old values to
new format.

Backpatch all the way, even though this changes a hash value in some
cases, because in those cases the hash value is already failing - for
example, a hash join between old- and new-format empty hstores will be
failing to match, or a hash index on an hstore column containing an
old-format empty value will be failing to find the value since it will
be searching for a hash derived from a new-format datum. (There are no
known field reports of this happening, probably because hashing of
hstores has only been useful in limited circumstances and there
probably isn't much upgraded data being used this way.)

Per concerns arising from discussion of commit eb6f29141be. Original
bug is my fault.

Discussion: https://postgr.es/m/60b1fd3b-7332-40f0-7e7f-f2f04f777747%402ndquadrant.com
contrib/hstore/hstore_compat.c