Tsunakawa, Takayuki wrote: > (Although unrelated to this, I've also been wondering why PostgreSQL > flushes WAL to disk when writing a page in the shared buffer, because > PostgreSQL doesn't use WAL for undo.)
The reason is that if the system crashes after writing the data page to disk, but before writing the WAL, the data page would be inconsistent with data in pages that weren't flushed, since there is no WAL to update those other pages. Also, if the system crashes after partially writing the page (say it writes the first 4kB) then the page is downright corrupted with no way to fix it. So there has to be a barrier that ensures that the WAL is flushed up to the last position that modified a page (i.e. that page's LSN) before actually writing that page to disk. And this is why we can't use mmap() for shared buffers -- there is no mechanism to force the WAL down if the operation system has the liberty to flush pages whenever it likes. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
