On Mon, Apr 9, 2018 at 8:56 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Apr 6, 2018 at 11:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> David Rowley <david.row...@2ndquadrant.com> writes: >>> Sounds like you're saying that if we have too many alternative files >>> then there's a chance that one could pass by luck. >> >> Yeah, exactly: it passed, but did it pass for the right reason? >> >> If there's just two expected-files, it's likely not a big problem, >> but if you have a bunch it's something to worry about. >> >> I'm also wondering how come we had hash partitioning before and >> did not have this sort of problem. Is it just that we added a >> new test that's more sensitive to the details of the hashing >> (if so, could it be made less so)? Or is there actually more >> platform dependence now than before (and if so, why is that)? > > The existing hash partitioning tests did have some dependencies on the > hash function, but they took care not to use the built-in hash > functions. Instead they did stuff like this: > > CREATE OR REPLACE FUNCTION hashint4_noop(int4, int8) RETURNS int8 AS > $$SELECT coalesce($1,0)::int8$$ LANGUAGE sql IMMUTABLE; > CREATE OPERATOR CLASS test_int4_ops FOR TYPE int4 USING HASH AS > OPERATOR 1 = , FUNCTION 2 hashint4_noop(int4, int8); > CREATE TABLE mchash (a int, b text, c jsonb) > PARTITION BY HASH (a test_int4_ops, b test_text_ops); > > I think that this approach should also be used for the new tests. > Variant expected output files are a pain to maintain, and you > basically just have to take whatever output you get as the right > answer, because nobody knows what output a certain built-in hash > function should produce for a given input except by running the code. > If you do the kind of thing shown above, though, then you can easily > see by inspection that you're getting the right answer.
+1. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
