Jeff Davis <pgsql@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
