Re: Potential Large Performance Gain in WAL synching
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Neil Conway <neilc@samurai.com>
Cc: "Curtis Faith" <curtis@galtair.com>, "Pgsql-Hackers" <pgsql-hackers@postgresql.org>
Date: 2002-10-05T03:13:44Z
Lists: pgsql-hackers
Neil Conway <neilc@samurai.com> writes: > "Curtis Faith" <curtis@galtair.com> writes: >> It looks to me like BufferAlloc will simply result in a call to >> BufferReplace > smgrblindwrt > write for md storage manager objects. >> >> This means that a process will block while the write of dirty cache >> buffers takes place. > I think Tom was suggesting that when a buffer is written out, the > write() call only pushes the data down into the filesystem's buffer -- > which is free to then write the actual blocks to disk whenever it > chooses to. Exactly --- in all Unix systems that I know of, a write() is asynchronous unless one takes special pains (like opening the file with O_SYNC). Pushing the data from userspace to the kernel disk buffers does not count as I/O in my mind. I am quite concerned about Curtis' worries about fsync, though. There's not any fundamental reason for fsync to block other operations, but that doesn't mean that it's been implemented reasonably everywhere :-(. We need to take a look at that. regards, tom lane