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

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/