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


So we don't even know whether we can read. I think that means we need to
zero the file anyway...


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