Re: Continuing instability in insert-conflict-specconflict test

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Continuing instability in insert-conflict-specconflict test
Date: 2020-08-24 20:42:35
Message-ID: 20200824204235.nexshsc5phkmkiah@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-08-24 21:21:27 Re: Continuing instability in insert-conflict-specconflict test
Previous Message Andres Freund 2020-08-24 20:26:40 Re: Hybrid Hash/Nested Loop joins and caching results from subplans