From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: posix_fadvise missing in the walsender |
Date: | 2013-02-19 20:19:26 |
Message-ID: | CAHyXU0xRQLWdsAme=uAHs6gT3GfWn-=qY5MZGzkSXx6caeRngQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Feb 18, 2013 at 2:16 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> On 17.02.2013 14:55, Joachim Wieland wrote:
>>
>> In access/transam/xlog.c we give the OS buffer caching a hint that we
>> won't need a WAL file any time soon with
>>
>> posix_fadvise(openLogFile, 0, 0, POSIX_FADV_DONTNEED);
>>
>> before closing the WAL file, but only if we don't have walsenders.
>> That's reasonable because the walsender will reopen that same file
>> shortly after.
>>
>> However the walsender doesn't call posix_fadvise once it's done with
>> the file and I'm proposing to add this to walsender.c for consistency
>> as well.
>>
>> Since there could be multiple walsenders, only the "slowest" one
>> should call this function. Finding out the slowest walsender can be
>> done by inspecting the shared memory and looking at the sentPtr of
>> each walsender.
>
>
> I doubt it's worth it, the OS cache generally does a reasonable job at
> deciding what to keep. In the non-walsender case, it's pretty clear that we
> don't need the WAL file anymore, but if we need to work any harder than a
> one-line posix_fadvise call, meh.
If that's the case, why have the advisory call at all? The OS is
being lied too (in some cases)...
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2013-02-19 20:38:46 | Re: [HACKERS] Call for Google Summer of Code mentors, admins |
Previous Message | Pavel Stehule | 2013-02-19 19:55:10 | Re: JSON Function Bike Shedding |