Re: fallocate / posix_fallocate for new WAL file creation (etc...)

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Date: 2013-05-29 02:10:54
Message-ID: 51A563AE.2090507@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/28/13 10:00 PM, Jon Nelson wrote:
> On Tue, May 28, 2013 at 10:36 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>> On 5/28/13 11:12 AM, Jon Nelson wrote:
>>>
>>> It opens a new file, fallocates 16MB, calls fdatasync.
>>
>>
>> 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.
>
> util-linux comes with fallocate which (might?) suffice for testing in
> that respect, no?
> If that is a real concern, it could be made part of the autoconf
> testing, perhaps.

I was just thinking of something to run in your test program, not
another build time check. Just run the new allocation sequence, and
then check the resulting WAL file for a) correct length, and b) 16K of
zero bytes. I would like to build some confidence that posix_fallocate
is operating correctly in this context on at least one platform. My
experience with Linux handling this class of functions correctly has
left me skeptical of them working until that's proven to be the case.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-05-29 02:55:20 Re: [GENERAL] pg_upgrade -u
Previous Message Andres Freund 2013-05-29 02:08:44 Re: preserving forensic information when we freeze