Re: Continuing instability in insert-conflict-specconflict test

2021-06-13 Thread Noah Misch
On Sun, Jun 13, 2021 at 04:49:04PM -0700, Andres Freund wrote: > 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 th

Re: Continuing instability in insert-conflict-specconflict test

2021-06-13 Thread Gavin Flower
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 annotatio

Re: Continuing instability in insert-conflict-specconflict test

2021-06-13 Thread Andres Freund
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

Re: Continuing instability in insert-conflict-specconflict test

2021-06-13 Thread Noah Misch
On Sun, Jun 13, 2021 at 06:09:20PM -0400, Tom Lane wrote: > Noah Misch writes: > > On Sun, Jun 13, 2021 at 04:48:48PM -0400, Tom Lane wrote: > >> * Adjust the test script's functions to emit a NOTICE *after* acquiring > >> a lock, not before. > > > I suspect that particular lock acquisition merel

Re: Continuing instability in insert-conflict-specconflict test

2021-06-13 Thread Tom Lane
Noah Misch writes: > On Sun, Jun 13, 2021 at 04:48:48PM -0400, Tom Lane wrote: >> * Adjust the test script's functions to emit a NOTICE *after* acquiring >> a lock, not before. > I suspect that particular lock acquisition merely unblocks the processing that > reaches the final lock state expected

Re: Continuing instability in insert-conflict-specconflict test

2021-06-13 Thread Noah Misch
On Sun, Jun 13, 2021 at 04:48:48PM -0400, Tom Lane wrote: > Noah Misch writes: > > On Tue, Aug 25, 2020 at 12:04:41PM -0400, Tom Lane wrote: > >> I think what we have to do to salvage this test is to get rid of the > >> use of NOTICE outputs, and instead have the test functions insert > >> log rec

Re: Continuing instability in insert-conflict-specconflict test

2021-06-13 Thread Tom Lane
Noah Misch writes: > The test material added in commit 43e0841 continues to yield buildfarm > failures. Yeah. It's only a relatively small fraction of the total volume of isolation-test failures, so I'm not sure it's worth expending a whole lot of effort on this issue by itself. > On Tue, Aug 2

Re: Continuing instability in insert-conflict-specconflict test

2021-06-13 Thread Noah Misch
The test material added in commit 43e0841 continues to yield buildfarm failures. Failures new since the rest of this thread: damselfly│ 2021-02-02 10:19:15 │ HEAD │ http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=damselfly&dt=2021-02-02%2010%3A19%3A15 drongo │ 2021-02

Re: Continuing instability in insert-conflict-specconflict test

2020-08-31 Thread Asim Praveen
Let me (rather shamelessly) extract a couple of patches from the patch set that was already shared in the fault injection framework proposal [1]. The first patch incorporates a new syntax in isolation spec grammar to explicitly mark a step that is expected to block (due to reasons other than locks

Re: Continuing instability in insert-conflict-specconflict test

2020-08-25 Thread Andrew Dunstan
On 8/24/20 4:42 PM, Andres Freund wrote: > > This test is really hairy, which isn't great. But until we have a proper > framework for controlling server side execution, I am not sure how we > better can achieve test coverage for this stuff. And there've been bugs, > so it's worth testing. > Wha

Re: Continuing instability in insert-conflict-specconflict test

2020-08-25 Thread Tom Lane
I wrote: > I've spent the day fooling around with a re-implementation of > isolationtester that waits for all its controlled sessions to quiesce > (either wait for client input, or block on a lock held by another > session) before moving on to the next step. That was not a feasible > approach befo

Re: Continuing instability in insert-conflict-specconflict test

2020-08-24 Thread Tom Lane
Andres Freund writes: > ISTM the issue at hand isn't so much that X expects something to be > printed by Y before it terminates, but that it expects the next step to > not be executed before Y unlocks. If I understand the wrong output > correctly, what happens is that "controller_print_speculative

Re: Continuing instability in insert-conflict-specconflict test

2020-08-24 Thread Andres Freund
On 2020-08-24 13:42:35 -0700, Andres Freund wrote: > Hi, > > On 2020-08-23 22:53:18 -0400, Tom Lane wrote: > > We've seen repeated failures in the tests added by commit 43e084197: > > ... > > I dug into this a bit today, and found that I can reproduce the failure > > reliably by adding a short del

Re: Continuing instability in insert-conflict-specconflict test

2020-08-24 Thread Andres Freund
Hi, On 2020-08-23 22:53:18 -0400, Tom Lane wrote: > We've seen repeated failures in the tests added by commit 43e084197: > ... > I dug into this a bit today, and found that I can reproduce the failure > reliably by adding a short delay in the right place, as attached. > > However, after studying

Continuing instability in insert-conflict-specconflict test

2020-08-23 Thread Tom Lane
We've seen repeated failures in the tests added by commit 43e084197: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=anole&dt=2020-08-23%2005%3A46%3A17 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2020-08-04%2001%3A05%3A30 https://buildfarm.postgresql.org/cgi-bin/show_lo