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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-11-30 16:04:05|
|Subject: Re: DELETE with LIMIT (or my first hack) |
|Previous:||From: Alexey Klyukin||Date: 2010-11-30 16:00:23|
|Subject: Another proposal for table synonyms|