On Thu, May 30, 2013 at 7:13 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
