Re: BUG #14150: Attempted to delete invisible tuple
От | Andres Freund |
---|---|
Тема | Re: BUG #14150: Attempted to delete invisible tuple |
Дата | |
Msg-id | 20160818204342.ktav5k7tenerom4v@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #14150: Attempted to delete invisible tuple (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #14150: Attempted to delete invisible tuple
Re: BUG #14150: Attempted to delete invisible tuple |
Список | pgsql-bugs |
On 2016-08-18 16:38:39 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2016-08-17 21:45:38 -0400, Tom Lane wrote: > >> guaibasaurus thinks this test is still underdetermined. > > > The easiest solution here seems to be another expected file - playing > > around a few minutes, I couldn't see an easier solution. Better ideas? > > If you think the two outcomes are equally valid, sure. Both are valid, yes. Will do that. > You could possibly try to force a single ordering by inserting a sleep > into some step of the test --- we have some other isolation tests that > do it that way. But it's hard to predict how much sleep is enough. I don't think it's applicable here - s2/3 are woken up by the same lock release. The order in which the OS lets them run primarily determines the result visibility. A sleep wouldn't hide the difference in output order afaics. I guess we could hide the combined steps (insert & sleep) in a function, but ... Andres
В списке pgsql-bugs по дате отправления: