From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Florian Weimer <fw(at)deneb(dot)enyo(dot)de> |
Cc: | shridhar(at)frodo(dot)hserus(dot)net, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint |
Date: | 2004-02-15 16:26:53 |
Message-ID: | 8526.1076862413@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-hackers-win32 |
Florian Weimer <fw(at)deneb(dot)enyo(dot)de> writes:
> Tom Lane wrote:
>> You can only fsync one FD at a time (too bad ... if there were a
>> multi-file-fsync API it'd solve the overspecified-write-ordering issue).
> What about aio_fsync()?
(1) it's unportable; (2) it's not clear that it's any improvement over
fsync(). The Single Unix Spec says aio_fsync "returns when the
synchronisation request has been initiated or queued to the file or
device". Depending on how the implementation works, this may mean that
all the dirty blocks have been scheduled for I/O and will be written
ahead of subsequently scheduled blocks --- if so, the results are not
really different from fsync()'ing the files in the same order.
The best idea I've heard so far is the one about sync() followed by
a bunch of fsync()s. That seems to be correct, efficient, and dependent
only on very-long-established Unix semantics.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2004-02-15 16:41:57 | Re: [SQL] 7.4 - FK constraint performance |
Previous Message | Andrew Dunstan | 2004-02-15 14:36:58 | Re: [HACKERS] dollar quoting |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-02-16 15:44:16 | Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint |
Previous Message | Florian Weimer | 2004-02-15 13:05:16 | Re: [pgsql-hackers-win32] Sync vs. fsync during checkpoint |