Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: > The trivial solution to this is to WAL-log setting the visibility map > bit, like we WAL-log any other operation. Lock the heap page, lock the > visibility map page, write WAL-record, and release locks. That works, > but the problem is that it creates quite a lot of new WAL traffic.
How much is "quite a lot"? Do we have any real reason to think that this solution is unacceptable performance-wise? I'd also suggest that if you want to prevent torn-page syndrome on VM pages (and if you want to rely on their LSN values, you do) then you probably don't have any choice anyway. VM pages will have to adhere to the same write-full-page-on-first-mod-after-checkpoint rule as any other page. I'd guess that this will swamp any savings from cutesy schemes for reducing the number of WAL records. > We could reduce the WAL traffic by simply updating multiple pages at a > time. Lock N pages, lock the visibility map page, write one WAL record, > and release locks. I don't think that will work, because you have to hold the lock on a page from the time you check that it's all-visible to the time you apply the update. The loss of concurrency against updates would be pretty bad, and I think you'd be creating significant risk of deadlocks from holding multiple buffer locks at once. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers