Re: Continuing instability in insert-conflict-specconflict test

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

In response to

Browse pgsql-hackers by date

  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