Re: Continuing instability in insert-conflict-specconflict test - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Continuing instability in insert-conflict-specconflict test
Date
Msg-id 20200824204235.nexshsc5phkmkiah@alap3.anarazel.de
Whole thread Raw
In response to Continuing instability in insert-conflict-specconflict test  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Continuing instability in insert-conflict-specconflict test
Re: Continuing instability in insert-conflict-specconflict test
List pgsql-hackers
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 the test awhile I have to admit that I do not
> understand why all these failures look the same, because it seems to
> me that this test is a house of cards.  It *repeatedly* expects that
> issuing a command to session X will result in session Y reporting
> some notice before X's command terminates, even though X's command will
> never meet the conditions for isolationtester to think it's blocked.
>
> AFAICS that is nothing but wishful thinking.  Why is it that only one of
> those places has failed so far?

Are there really that many places expecting that? I've not gone through
this again exhaustively by any means, but most places seem to print
something only before waiting for a lock.

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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Hybrid Hash/Nested Loop joins and caching results from subplans
Next
From: Andres Freund
Date:
Subject: Re: Continuing instability in insert-conflict-specconflict test