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

From: Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, 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-07-05 13:21:01
Message-ID: CAKuK5J0JObq_y-LF311PVOaN-qx16O5j1BVNeErVdCQyE+WryQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 5, 2013 at 2:23 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> On 7/5/13 2:50 AM, Jeff Davis wrote:
>>
>> So, my simple conclusion is that glibc emulation should be about the
>> same as what we're doing now, so there's no reason to avoid it. That
>> means, if posix_fallocate() is present, we should use it, because it's
>> either the same (if emulated in glibc) or significantly faster (if
>> implemented in the kernel).
>
>
> That's what I'm seeing everywhere too. I'm happy that we've spent enough
> time chasing after potential issues without finding anything now. Pull out
> the GUC that was added for default and this is ready to commit.

Wonderful. Is removing the GUC something that I should do or should
that be done by somebody that knows more about what they are doing? (I
am happy to give it a go!)

Should the small test program that I made also be included somewhere
in the source tree?

--
Jon

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-07-05 13:25:13 Re: changeset generation v5-01 - Patches & git tree
Previous Message Hari Babu 2013-07-05 13:17:55 Re: Review: Patch to compute Max LSN of Data Pages