Re: [PATCH] Btree BackwardScan race condition on Standby duringVACUUM

Поиск
Список
Период
Сортировка
От Andrey M. Borodin
Тема Re: [PATCH] Btree BackwardScan race condition on Standby duringVACUUM
Дата
Msg-id 484E2002-DC57-4D7D-AE0B-4B09C9AB616B@yandex-team.ru
обсуждение исходный текст
Ответ на [PATCH] Btree BackwardScan race condition on Standby during VACUUM  (Michail Nikolaev <michail.nikolaev@gmail.com>)
Ответы Re: [PATCH] Btree BackwardScan race condition on Standby during VACUUM  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
Hi Michail!

Very interesting bug.

> 16 марта 2020 г., в 19:07, Michail Nikolaev <michail.nikolaev@gmail.com> написал(а):
>
> So, I think right way is to lock all three pages as it is done on the
> primary. As far as I can see it is not causes any real performance
> regression.

It seems to me that it's exactly the same check that I was trying to verify in amcheck patch [0].
But there it was verified inside amcheck, but here it is verified by index scan.

Basically, one cannot check that two vice-versa pointers are in agreement without locking both.
As a result, they must be changed under lock too.

In my view, lock coupling is necessary here. I'm not sure we really need to lock three pages though.

Is there a reason why concurrency protocol on standby should not be exactly the same as on primary?


Best regards, Andrey Borodin.

[0] https://commitfest.postgresql.org/24/2254/


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

Предыдущее
От: Paul A Jungwirth
Дата:
Сообщение: Re: range_agg
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: ALTER tbl rewrite loses CLUSTER ON index