From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PGOPTIONS="-fh" make check gets stuck since Postgres 11 |
Date: | 2019-07-10 13:45:47 |
Message-ID: | 1548.1562766347@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Wed, Jul 10, 2019 at 12:51:28PM +0530, Amit Kapila wrote:
>> It would be good if we can come up with something like that. It will
>> be helpful for zheap, where in some cases we get different row
>> ordering due to in-place updates. As of now, we try to add Order By
>> or do some extra magic to get consistent row ordering.
> That was an issue for me as well when working with Postgres-XC when
> the row ordering was not guaranteed depending on the number of nodes
> (speaking of which Greenplum has the same issues, no?). Adding ORDER
> BY clauses to a set of tests may make sense, but then this may impact
> the plans generated for some of them..
Yeah, I do not want to get into a situation where we can't test
queries that lack ORDER BY. Also, the fact that tableam X doesn't
reproduce heap's row ordering is not a good reason to relax the
strength of the tests for heap. So I'm wondering about some
postprocessing that we could optionally apply. Perhaps the tools
Melanie mentions could help.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2019-07-10 13:59:06 | Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status) |
Previous Message | Alvaro Herrera | 2019-07-10 13:38:03 | Re: Contribution to Perldoc for TestLib module in Postgres |