On 7 April 2018 at 12:43, David Rowley <david.rowley@2ndquadrant.com> wrote:
> On 7 April 2018 at 12:35, Amit Langote <amitlangote09@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
