Re: Continuing instability in insert-conflict-specconflict test
От
Andres Freund
Тема
Re: Continuing instability in insert-conflict-specconflict test
Дата
Msg-id
20200824204235.nexshsc5phkmkiah@alap3.anarazel.de
Ответ на
Список
Дерево обсуждения
Continuing instability in insert-conflict-specconflict test Tom Lane <tgl@sss.pgh.pa.us>
Re: Continuing instability in insert-conflict-specconflict test Andres Freund <andres@anarazel.de>
Re: Continuing instability in insert-conflict-specconflict test Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Re: Continuing instability in insert-conflict-specconflict test Andres Freund <andres@anarazel.de>
Re: Continuing instability in insert-conflict-specconflict test Tom Lane <tgl@sss.pgh.pa.us>
Re: Continuing instability in insert-conflict-specconflict test Tom Lane <tgl@sss.pgh.pa.us>
Re: Continuing instability in insert-conflict-specconflict test Noah Misch <noah@leadboat.com>
Re: Continuing instability in insert-conflict-specconflict test Tom Lane <tgl@sss.pgh.pa.us>
Re: Continuing instability in insert-conflict-specconflict test Noah Misch <noah@leadboat.com>
Re: Continuing instability in insert-conflict-specconflict test Tom Lane <tgl@sss.pgh.pa.us>
Re: Continuing instability in insert-conflict-specconflict test Noah Misch <noah@leadboat.com>
Re: Continuing instability in insert-conflict-specconflict test Andres Freund <andres@anarazel.de>
Re: Continuing instability in insert-conflict-specconflict test Noah Misch <noah@leadboat.com>
Re: Continuing instability in insert-conflict-specconflict test Gavin Flower <GavinFlower@archidevsys.co.nz>
Re: Continuing instability in insert-conflict-specconflict test Asim Praveen <pasim@vmware.com>
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 по дате отправления
От: Andres Freund
Дата:
От: Andres Freund
Дата: