"Tom Lane" <tgl@sss.pgh.pa.us> wrote
>
> This patch scares the heck out of me. You need to offer some pretty
> compelling performance reasons before I'd accept any part of it,
> Changing a buffer you hold no lock on is a recipe for disaster.
>
Me too, in fact :-(.
The overall performance improvement might be marginal but why not if it is
right. What I cares is the correctness. As I understand, the orginal code
puts a shared lock (1) to prevent the vacuum process to move tuples around
so the hint bits change may happen in a wrong place; (2) to prevent other
operations holding EXCLUSIVE lock to change bits at the same time. This
patch makes sure that (1) can't happen. For (2), the original code has a
similar pitfalls -- if we only hold shared lock, then two process reach here
can change the bits at the same time.
Regards,
Qingqing