Re: crash-safe visibility map, take three

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: crash-safe visibility map, take three
Дата
Msg-id 4CF52B1E.3040106@enterprisedb.com
обсуждение исходный текст
Ответ на Re: crash-safe visibility map, take three  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: crash-safe visibility map, take three  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: crash-safe visibility map, take three  (Robert Haas <robertmhaas@gmail.com>)
Re: crash-safe visibility map, take three  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On 30.11.2010 18:33, Tom Lane 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.

If you change the LSN on the heap pages, you have to write full page 
images of those as well.

Let's recap what happens when a VM bit is set: You set the 
PD_ALL_VISIBLE flag on the heap page (assuming it's not set already, it 
usually isn't), and then set the bit in the VM while keeping the heap 
page locked.

Can we get away with not setting the LSN on the heap page, even though 
we set the PD_ALL_VISIBLE flag? If we don't set the LSN, the heap page 
can be flushed to disk before the WAL record, but I think that's fine 
because it's OK to have the flag set in the heap page even if the VM bit 
is not set.

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


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

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