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..


Andres Freund

 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to