Re: crash-safe visibility map, take three - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: crash-safe visibility map, take three
Date
Msg-id 4CF51FFD.8030006@enterprisedb.com
Whole thread Raw
In response to Re: crash-safe visibility map, take three  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: crash-safe visibility map, take three
List pgsql-hackers
Here's one more idea:

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.

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. If N=10, for example, we only need to WAL-log a 
couple of bytes per page, so the WAL volume should be acceptable. The 
downside is that you need to keep more pages locked at the same time, 
but maybe that's not too bad.

This wouldn't require anything special, which means fewer hard-to-debug 
visibility & recovery bugs.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: crash-safe visibility map, take three
Next
From: Tom Lane
Date:
Subject: Re: DELETE with LIMIT (or my first hack)