On Thu, May 30, 2013 at 7:13 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> 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.
I think they didn't specify it because it IS obvious. As Stephen
says, it's been understood for decades that allowing unzeroed pages to
be reallocated to some other file is a major security hole. I think
we can assume that no credible OS does that. If there's some OS out
there that chooses to fill the pre-extended pages with 0x55 or cat
/dev/urandom instead of 0x00, they probably deserve what they get.
It's hard for me to be believe that anything that silly actually
exists.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
