Re: fallocate / posix_fallocate for new WAL file creation (etc...) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Date
Msg-id 20130530125038.GQ6434@tamriel.snowman.net
Whole thread Raw
In response to Re: fallocate / posix_fallocate for new WAL file creation (etc...)  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: fallocate / posix_fallocate for new WAL file creation (etc...)  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
* Andres Freund (andres@2ndquadrant.com) wrote:
> On 2013-05-30 08:19:17 -0400, Peter Eisentraut wrote:
> > On 5/30/13 8:02 AM, Robert Haas wrote:
> > > If there's some OS out
> > > there that chooses to fill the pre-extended pages with 0x55 or cat
> > > /dev/urandom instead of 0x00, they probably deserve what they get.
> >
> > Even that wouldn't be a problem for our purpose.  The only problem would
> > be if you can't read from the allocated region at all.
>
> Well, only as long as we only use it for preallocation of wal files. I
> am much, much more interested in doing that for the heap. And there that
> surely would be a problem.

Yes, that was my thinking as well.  If posix_fallocate is faster than
writing out 8K of zeros, and the block can immediately be read as if it
had actually been written to, then I'd be very interested in using it to
extend heap files.  As I mentioned in this thread (or perhaps it was
another), I don't think this solves the locking issue around the
relation extention lock, but it might help some and it may make it
easier to tweak that logic to allocate larger chunks in the future.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Next
From: Stephen Frost
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)