On 21.08.2011 07:10, Gokulakannan Somasundaram wrote:
d) In addition, currently there is no WAL Logging, while the bit is
cleared,
which would not be the case in future and hence the exclusive lock held
on
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
implemented.
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:
http://www.postgresql.org/mailpref/pgsql-hackers
