Re: fallocate / posix_fallocate for new WAL file creation (etc...)
От | Andres Freund |
---|---|
Тема | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
Дата | |
Msg-id | 20130530122820.GB14029@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: fallocate / posix_fallocate for new WAL file creation (etc...) (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: fallocate / posix_fallocate for new WAL file creation
(etc...)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: