Re: failures in t/031_recovery_conflict.pl on CI
От | Tom Lane |
---|---|
Тема | Re: failures in t/031_recovery_conflict.pl on CI |
Дата | |
Msg-id | 1959496.1651555006@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: failures in t/031_recovery_conflict.pl on CI (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: failures in t/031_recovery_conflict.pl on CI
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2022-05-02 23:44:32 -0400, Tom Lane wrote: >> I can poke into that tomorrow, but are you sure that that isn't an >> expectable result? > It's not expected. But I think I might see what the problem is: > We wait for the FETCH (and thus the buffer pin to be acquired). But that > doesn't guarantee that the lock has been acquired. We can't check that with > pump_until() afaics, because there'll not be any output. But a query_until() > checking pg_locks should do the trick? Irritatingly, it doesn't reproduce (at least not easily) in a manual build on the same box. So it's almost surely a timing issue, and your theory here seems plausible. regards, tom lane
В списке pgsql-hackers по дате отправления: