Re: WAL write of full pages

Поиск
Список
Период
Сортировка
Искать
От
Shridhar Daithankar
Тема
Re: WAL write of full pages
Дата
Msg-id
40570A90.1040708@frodo.hserus.net
Ответ на
Список
Дерево обсуждения
Re: WAL write of full pages Marty Scholes <marty@outputservices.com>
Bruce Momjian wrote:

> Shridhar Daithankar wrote:
>>I can not see why writing an 8K block is any more safe than writing just the 
>>changes.
>>
>>I may be dead wrong but just putting my thoughts together..
> The problem is that we need to record what was on the page before we
> made the modification because there is no way to know that a write
> hasn't corrupted some part of the page.

OK... I think there is hardly any way around the fact that we need to flush a 
page the way we do it now. But that is slow. So what do we do.

How feasible it would be to push fsyncing those pages/files to background writer 
and have it done on priority? That way the disk IO wait could get out of 
critical execution path. May be that could yield the performance benefit we are 
looking for.

Also just out of curiosity. Is it possbile that more than one transaction grab 
hold of different pages of WAL and start putting data to it simaltenously? In 
such a case a single fsync could do the job for more than one backend but 
replaying WAL would be akin to defragging a FAT partition..

Just a thought..
 Shridhar

В списке pgsql-hackers по дате отправления
От: Bruce Momjian
Дата:
От: Dennis Haney
Дата:
Сообщение: Re: WAL write of full pages
FAQ