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 |
Thread: | |
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
Regards,
Jeff Davis
Attachment | Content-Type | Size |
---|---|---|
fallocate.c | text/x-csrc | 341 bytes |
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 |