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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
