Heikki Linnakangas <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
