Re: Visibility map, partial vacuums

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> To modify a page:
> If PD_ALL_VISIBLE flag is set, the bit in the visibility map is cleared 
> first. The heap page is kept pinned, but not locked, while the 
> visibility map is updated. We want to avoid holding a lock across I/O, 
> even though the visibility map is likely to stay in cache. After the 
> visibility map has been updated, the page is exclusively locked and 
> modified as usual, and PD_ALL_VISIBLE flag is cleared before releasing 
> the lock.

So after having determined that you will modify a page, you release the
ex lock on the buffer and then try to regain it later?  Seems like a
really bad idea from here.  What if it's no longer possible to do the
modification you intended?

> To set the PD_ALL_VISIBLE flag, you must hold an exclusive lock on the 
> page, while you observe that all tuples on the page are visible to everyone.

That doesn't sound too good from a concurrency standpoint...

> That's how the patch works right now. However, there's a small 
> performance problem with the current approach: setting the 
> PD_ALL_VISIBLE flag must be WAL-logged. Otherwise, this could happen:

I'm more concerned about *clearing* the bit being WAL-logged.  That's
necessary for correctness.
        regards, tom lane