On Sat, Apr 7, 2018 at 10:31 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> 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?
Yeah, that's an idea.
Is it alright though that same data may end up in different hash
partitions depending on the architecture? IIRC, that's the way we
decided to go when using hash partitioning, but it would've been
clearer if there was already some evidence in regression tests that
that's what we've chosen, such as, some existing tests for tuple
routing.
Thanks,
Amit