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. Maybe that's OK, because I can't see that we'd ever acquire any other buffer content lock while already holding a lock on the visibility map buffer. But given this logic, if we did do such a thing, it could result in an undetected deadlock. Hmm.... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
