On 7 April 2018 at 12:43, David Rowley <david.row...@2ndquadrant.com> wrote: > On 7 April 2018 at 12:35, Amit Langote <amitlangot...@gmail.com> wrote: >> So this same failure occurs on (noting the architecture): >> >> Seems to be due to that the hashing function used in partitioning >> gives different answer for a given set of partition key values than >> others. > > They all look like bigendian CPUs.
I looked at all the regression test diffs for each of the servers you mentioned and I verified that the diffs match on each of the 7 servers. Maybe the best solution is to pull those tests out of partition_prune.sql then create partition_prune_hash and just have an alternative .out file with the partitions which match on bigendian machines. We could also keep them in the same file, but that's a much bigger alternative file to maintain and more likely to get broken if someone forgets to update it. What do you think? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
