On 2013-05-29 10:36:07 -0400, Stephen Frost wrote: > * Peter Eisentraut (pete...@gmx.net) wrote: > > On 5/28/13 11:36 AM, Greg Smith wrote: > > > Outside of the run for performance testing, I think it would be good at > > > this point to validate that there is really a 16MB file full of zeroes > > > resulting from these operations. I am not really concerned that > > > posix_fallocate might be slower in some cases; that seems unlikely. I > > > am concerned that it might result in a file that isn't structurally the > > > same as the 16MB of zero writes implementation used now. > > > > I see nothing in the posix_fallocate() man pages that says that the > > allocated space is filled with any kind of data or zeroes. It will > > likely be garbage data, but that should be fine for a new WAL file. > > I *really* hope that the Linux kernel, and other, folks are smart enough > to realize that they can't just re-use random blocks from an I/O device > without cleaning it first.
FWIW, posix' description about posix_fallocate() doesn't actually say *anything* about reading. The guarantee it makes is: "If posix_fallocate() returns successfully, subsequent writes to the specified file data shall not fail due to the lack of free space on the file system storage media.". http://pubs.opengroup.org/onlinepubs/009696799/functions/posix_fallocate.html So we don't even know whether we can read. I think that means we need to zero the file anyway... 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
