From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | "Curtis Faith" <curtis(at)galtair(dot)com>, "Pgsql-Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Potential Large Performance Gain in WAL synching |
Date: | 2002-10-05 03:13:44 |
Message-ID: | 404.1033787624@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)com> writes:
> "Curtis Faith" <curtis(at)galtair(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Curtis Faith | 2002-10-05 03:16:52 | Re: Potential Large Performance Gain in WAL synching |
Previous Message | Joe Conway | 2002-10-05 01:14:58 | Re: Improving backend startup interlock |