On 2012-11-16 17:19:23 -0800, Jeff Davis wrote: > On Fri, 2012-11-16 at 16:09 +0100, Andres Freund wrote: > > As far as I understand the code the crash-safety aspects of the > > visibilitymap currently rely on on having the knowledge that ALL_VISIBLE > > has been cleared during a heap_(insert|update|delete). That allows > > management of the visibilitymap without it being xlogged itself which > > seems pretty important to me. > > It looks like the xlrec does contain a "cleared all visible" flag in it, > and it uses that to clear the VM as well as PD_ALL_VISIBLE.
I think the point is that to check whether the visibilitymap bit needs to be unset - and thus locked exlusively - no locks have to be acquired but those heap_* already has. Given that in a the large amount of cases ALL_VISIBLE does *not* need to be reset I think that this is a very important property for concurrency purposes. If you consider the large amount of pages that are covered by a single visibilitymap page we don't want more locking in that path... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
