On 2013-05-30 08:02:56 -0400, Robert Haas wrote: > 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.
I don't think there's much danger of getting uninitialized data or such. That clearly would be insane. I think somebody might interpret it as read(2) returning an error until the page has been written to which isn't completely crazy. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers