Re: deadlock-hard flakiness

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: deadlock-hard flakiness
Дата
Msg-id 20230208070603.5npdezbrcpnemfx4@awork3.anarazel.de
обсуждение исходный текст
Ответ на deadlock-hard flakiness  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi,

On 2023-02-07 17:10:21 -0800, Andres Freund wrote:
> So far the diff always is:
> 
> diff -U3 /tmp/cirrus-ci-build/src/test/isolation/expected/deadlock-hard.out
/tmp/cirrus-ci-build/build/testrun/isolation-running/isolation/results/deadlock-hard.out
> --- /tmp/cirrus-ci-build/src/test/isolation/expected/deadlock-hard.out    2023-02-07 05:32:34.536429000 +0000
> +++ /tmp/cirrus-ci-build/build/testrun/isolation-running/isolation/results/deadlock-hard.out    2023-02-07
05:40:33.833908000+0000
 
> @@ -25,10 +25,11 @@
>  step s6a7: <... completed>
>  step s6c: COMMIT;
>  step s5a6: <... completed>
> -step s5c: COMMIT;
> +step s5c: COMMIT; <waiting ...>
>  step s4a5: <... completed>
>  step s4c: COMMIT;
>  step s3a4: <... completed>
> +step s5c: <... completed>
>  step s3c: COMMIT;
>  step s2a3: <... completed>
>  step s2c: COMMIT;

While trying to debug the create_index issue [1], I did end up hitting a
deadlock-soft output difference:

https://cirrus-ci.com/task/6332011665686528
diff -U3 /tmp/cirrus-ci-build/src/test/isolation/expected/deadlock-soft.out
/tmp/cirrus-ci-build/build/testrun/isolation-running/isolation/results/deadlock-soft.out
--- /tmp/cirrus-ci-build/src/test/isolation/expected/deadlock-soft.out    2023-02-08 06:55:17.620898000 +0000
+++ /tmp/cirrus-ci-build/build/testrun/isolation-running/isolation/results/deadlock-soft.out    2023-02-08
06:56:17.622621000+0000
 
@@ -8,10 +8,13 @@
 step d1a2: LOCK TABLE a2 IN ACCESS SHARE MODE; <waiting ...>
 step d2a1: LOCK TABLE a1 IN ACCESS SHARE MODE; <waiting ...>
 step d1a2: <... completed>
-step d1c: COMMIT;
+step d1c: COMMIT; <waiting ...>
 step e1l: <... completed>
 step e1c: COMMIT;
 step d2a1: <... completed>
-step d2c: COMMIT;
+step d1c: <... completed>
+step d2c: COMMIT; <waiting ...>
 step e2l: <... completed>
-step e2c: COMMIT;
+step e2c: COMMIT; <waiting ...>
+step d2c: <... completed>
+step e2c: <... completed>


Like in the deadlock-hard case, I don't understand how the commits suddenly
end up being considered waiting.

Greetings,

Andres Freund

[1] https://www.postgresql.org/message-id/20230208024748.ijvwabhqu4xlbvin%40awork3.anarazel.de



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Cygwin cleanup