On 2013-05-30 06:49:42 -0400, Robert Haas wrote: > On Wed, May 29, 2013 at 10:42 AM, Andres Freund <and...@2ndquadrant.com> > wrote: > > FWIW, posix' description about posix_fallocate() doesn't actually say > > *anything* about reading. The guarantee it makes is: > > "If posix_fallocate() returns successfully, subsequent writes to the > > specified file data shall not fail due to the lack of free space on the > > file system storage media.". > > > > http://pubs.opengroup.org/onlinepubs/009696799/functions/posix_fallocate.html > > > > So we don't even know whether we can read. I think that means we need to > > zero the file anyway... > > Surely this is undue pessimism.
Why? The spec doesn't specify that case and that very well allows other behaviour. Glibc sure does behave sensibly and zeroes the data (sysdeps/posix/posix_fallocate64.c for the generic implementation) and so does linux' fallocate() syscall, but that doesn't say much about other implementations. None of the manpages I could find, nor the spec says anything about the file's contents in the extended range. Given there were at least three manpages of different origins that didn't specify that behaviour I am not too optimistic. Why they didn't specify that completely obvious question is hard to understand from my pov. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
