Dennis Haney wrote:
> Bruce Momjian wrote:
>
>>Our current WAL implementation writes copies of full pages to WAL before
>>modifying the page on disk. This is done to prevent partial pages from
>>being corrupted in case the operating system crashes during a page
>>write.
>>
>>
> InnoDB uses a doublebuffer system instead.
> http://www.innodb.com/ibman.php#File.space.management
>
> quote:
>
> Starting from 3.23.40b, InnoDB uses a novel file flush technique called
> "doublewrite". It adds safety to crash recovery after an operating
> system crash or a power outage, and improves performance on most Unix
> flavors by reducing the need for |fsync()| operations.
>
> Doublewrite means that InnoDB before writing pages to a data file first
> writes them to a contiguous tablespace area called the doublewrite
> buffer. Only after the write and the flush to the doublewrite buffer has
> completed, InnoDB writes the pages to their proper positions in the data
> file. If the operating system crashes in the middle of a page write,
> InnoDB will in recovery find a good copy of the page from the
> doublewrite buffer.
That is what postgresql calls as WAL(Write Ahead Log).
The issue here is that WAL itself could become bottleneck since it is hit very
frequently with heavy load. So how do we speed up WAL itself.
Shridhar