On Sat, Apr 7, 2018 at 8:55 AM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 7 April 2018 at 15:14, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> On Sat, Apr 7, 2018 at 8:37 AM, David Rowley >>> Why is writing tests that produce the same output required? >>> >>> We have many tests with alternative outputs. Look in >>> src/tests/regress/expected for files matching _1.out >>> >> >> That's true, but we usually add such alternative output when we know >> all the variants possible as long as "all the variants" do not cover >> everything possible. AFAIU, that's not true here. Also, on a given >> machine a particular row is guaranteed to fall in a given partition. >> On a different machine it will fall in some other partition, but >> always that partition on that machine. We don't have a way to select >> alternate output based on the architecture. May be a better idea is to >> use .source file, creating .out on the fly based on the architecture >> of machine like testing the hash output for a given value to decide >> which partition it will fall into and then crafting .out with that >> partition's name. > > Sounds like you're saying that if we have too many alternative files > then there's a chance that one could pass by luck.
Yes. > > Maybe we can just back up what's just been committed by actually > executing the queries and ensuring that all rows that made it into the > table make it back out again. That's one way. But how would we make sure that they landed in proper partition. Actually we do not know what's proper partition for a given architecture. And how would we make sure that all rows with the same partition key land in the same partition. That's why I am suggesting to calculate the hash value, take modulo and craft the name of partition where corresponding row will land on a given architecture. That way, we are sure that the tuple routing logic is correct and also the partition pruning logic. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
