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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
15 matches
Mail list logo