On 2013-05-30 08:17:28 -0400, Peter Eisentraut wrote:
> On 5/30/13 7:13 AM, Andres Freund wrote:
> > 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.
>
> glibc actually only writes one byte to every file system block, to make
> sure the block is allocated. It doesn't actually zero every byte.
Which is fine since that guarantees we can read from those areas... And
unless I misremember something that actually guarantees that the rest of
the data is initialized to zero as well. Yes: "subsequent reads of data
in the gap shall return bytes with the value 0 until data is actually
written into the gap".
But really, I am not at all concerned about some obscure values being
returned, but about a read() not being successful..
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services