Jeff Davis <pg...@j-davis.com> writes: > On Mon, 2012-06-18 at 20:57 +0200, Andres Freund wrote: >> Ok. Sensible reasons. I dislike that we know have two files using different >> logic (copydir.c only using fadvise, initdb using sync_file_range if >> available). Maybe we should just move the fadvise and sync_file_range calls >> into its own common function?
> I don't see fadvise in copydir.c, it looks like it just uses fsync. It > might speed it up to use a pre-sync call there, too -- database creation > does take a while. No, that's incorrect: the fadvise is there, inside pg_flush_data() which is done during the writing phase. It seems to me that if we think sync_file_range is a win, we ought to be using it in pg_flush_data just as much as in initdb. However, I'm a bit confused because in http://archives.postgresql.org/pgsql-hackers/2012-03/msg01098.php you said > So, it looks like fadvise is the "right" thing to do, but I expect we'll Was that backwards? If not, why are we bothering with taking any portability risks by adding use of sync_file_range? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
