On 19.08.2011 23:17, Robert Haas wrote:
On Fri, Aug 19, 2011 at 4:02 PM, Robert Haas<robertmh...@gmail.com> wrote:
Hmm, you have a point. If 100 backends simultaneously write to 100
different pages, and all of those pages are all-visible, then it's
possible that they could end up fighting over the buffer content lock
on the visibility map page. But why would you expect that to matter?
In a heavily updated table, the proportion of visibility map bits that
are set figures to be quite low, since they're only set during VACUUM.
To have 100 backends simultaneously pick different pages to write
each of which is all-visible seems really unlucky. Even if it does
happen from time to time, I suspect the effects would be largely
masked by WALInsertLock contention. The visibility map content lock
is only taken very briefly, whereas the operations protected by
WALInsertLock are much more complex.
Oh, snap. I see another possible problem here.
At the time visibilitymap_clear() is called, we're already (and
necessarily) holding a content lock on the buffer. And then we go get
a content lock on the visibility map page, whose buffer number might
be higher or lower than that of the heap page, possibly leading us to
violate the rule the buffer content locks must be taken increasing
buffer number order.
Huh? The rule is that you have to acquire locks on heap pages in
increasing page number order. That doesn't apply to the order between
the heap and the visibility map. The rule we've established for that is
that you have to acquire the lock on the heap page first, before locking
the corresponding vm page. It would be good to add a comment about that
to the header comment of RelationGetBufferForTuple(), there doesn't seem
to be anything about the visibility map buffer arguments there.
--
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
