From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Continuing instability in insert-conflict-specconflict test |
Date: | 2021-06-14 00:23:24 |
Message-ID: | f4ab5ed3-3919-4df2-62e4-7a8da94e8198@archidevsys.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14/06/21 11:49 am, Andres Freund wrote:
> Hi,
>
> On 2021-06-13 15:22:12 -0700, Noah Misch wrote:
>> On Sun, Jun 13, 2021 at 06:09:20PM -0400, Tom Lane wrote:
>>> We might be able to get rid of the stuff about concurrent step
>>> completion in isolationtester.c if we required the spec files
>>> to use annotations to force a deterministic step completion
>>> order in all such cases.
>> Yeah. If we're willing to task spec authors with that, the test program can't
>> then guess wrong under unusual timing.
> I think it'd make it *easier* for spec authors. Right now one needs to
> find some way to get a consistent ordering, which is often hard and
> complicates tests way more than specifying an explicit ordering
> would. And it's often unreliable, as evidenced here and in plenty other
> tests.
>
> Greetings,
>
> Andres Freund
How about adding a keyword like 'DETERMINISTIC' to the top level SELECT,
the idea being the output would be deterministic (given the same table
values after filtering etc), but not necessarily in any particular
order? So pg could decide the optimum way to achieve that which may not
necessarily need a sort.
Cheers,
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2021-06-14 00:24:14 | Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier? |
Previous Message | Andres Freund | 2021-06-13 23:49:04 | Re: Continuing instability in insert-conflict-specconflict test |