Re: crash-safe visibility map, take three

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: crash-safe visibility map, take three
Дата
Msg-id AANLkTimD2ACTWWiCJowuoh9t5w79bxFVmnsvaqLxBdTi@mail.gmail.com
обсуждение исходный текст
Ответ на Re: crash-safe visibility map, take three  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Nov 30, 2010 at 11:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Oh, but it's worse than that.  When you XLOG a WAL record for each of
>> those pages, you're going to trigger full-page writes for all of them.
>>  So now you've turned 1GB of data to write into 2+ GB of data to
>> write.
>
> No, because only the first mod of each VM page would trigger a full page
> write, at least assuming a reasonable ordering of the operations.

I'm not worried about the full-page writes from updating the
visibility map - I'm worried about the full-page writes from updating
the heap.  It doesn't matter a whit if we fail to set a bit in the
visibility map. What matters is if we DO set the bit in the visibility
map but FAIL TO set the bit in the heap, because then a subsequent
update to the heap page won't check the visibility map and clear the
bit.  The *heap* updates are the ones that have to be guaranteed to
make it to disk.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: crash-safe visibility map, take three
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: crash-safe visibility map, take three