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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Greg Smith <greg(at)2ndQuadrant(dot)com>
Cc: Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, 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-06-30 18:01:53
Message-ID: 1372615313.19747.13.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Tue, 2013-05-28 at 22:10 -0400, Greg Smith wrote:
> 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.

As I understand it, you are basically asking if posix_fallocate() works
at all anywhere.

Simple test program attached, which creates two files and fills them:
one by 2048 8KB writes; and another by 1 posix_fallocate of 16MB. Then,
I just cmp the resulting files (and also "ls" them, to make sure they
are 16MB).

Passes on my workstation:
$ uname -a
Linux jdavis 3.5.0-34-generic #55-Ubuntu SMP Thu Jun 6 20:18:19 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

Jeff Davis

Attachment Content-Type Size
fallocate.c text/x-csrc 341 bytes

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2013-06-30 18:11:58 Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Previous Message Pavel Stehule 2013-06-30 17:08:07 Re: review: Non-recursive processing of AND/OR lists