On 2013-05-30 06:49:42 -0400, Robert Haas wrote:
> On Wed, May 29, 2013 at 10:42 AM, Andres Freund <andres@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
