On 21.08.2011 07:10, Gokulakannan Somasundaram wrote:
d) In addition, currently there is no WAL Logging, while the bit is
which would not be the case in future and hence the exclusive lock held
the visibility map is going to be held for a longer time.

This is false and has been false since the visibility map was first

I can't understand this. If you are not doing this, then it would cause
consistency issues. Are you saying, we have a crash safe visibility map, but
you don't follow "log the change before changing the contents"/ WAL
principle. If so, please explain in detail. If you are doing it in the
normal way, then you should be logging the changes before making the changes
to the buffer and during that timeframe, you should be holding the lock on
the buffer. Heikki specifically pointed out, that you have brought in the
WAL Logging of visibility map, within the critical section.

I think you two are talking slightly past each other. There is no extra WAL record written when a bit is cleared in the visibility map, there is just a flag in the WAL record of the heap insert/update/delete. That is what Robert was trying to explain, that part hasn't changed since 8.4. What *did* change, however, in master, when the visibility map was made crash-safe, is the duration the lock on the visibility map page is held. Before that, the visibility map page was locked only briefly *after* the changes to the heap page were already applied and WAL record written. Now, the VM page lock is acquired and released at the same time as the lock on the heap page. It's held while the heap page changes are made and WAL record is written. I believe that's what Gokulakannan was trying to point out, and is worried that you might get contention on the VM page lock now because it's held for a much longer duration.

Gokulakannan, if you could come up with a test case that demonstrates that contention (or the lack thereof), that would be good. Otherwise we're just speculating.

If it's an issue, perhaps we could release the VM page lock early. We're not updating the LSN on it, so we don't need to wait for the WAL record to be written, I think. It's a bit out of the ordinary, though, so I wouldn't like to do that without an actual test case that shows it's an issue.

  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to