Re: Page-at-a-time Locking Considerations

"Zdenek Kotala" <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:

> Tom Lane wrote:
>> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>>> Tom Lane wrote:
>>>> If you only got 2% out of it, it's not even worth thinking about how to
>>>> fix the serious bugs that approach would create (primarily, lack of
>>>> control over when pages can get flushed to disk).
>>
>>> You can flush a pages by msync() function which writes dirty pages on disk.
>>> I don't see any other problem.
>>
>> Then you need to learn more. The side of the problem that is hard to
>> fix is that sometimes we need to prevent pages from being flushed to
>> disk until some other data (typically WAL entries) has reached disk.
>> With mmap'd data we have no control over early writes.
>
> I see. Thanks for explanation.

In theory mlock() ought to provide that facility. The kernel people know it's
used by crypto software to avoid having disk copies of sensitive keys, so
there's at least a fighting chance it actually works for this too. But I
wouldn't put too much money on it working this purpose on every platform that
has it.

It's entirely conceivably that some platforms have mlock avoid swapping out
pages but not avoid syncing them but leaving them in RAM. Or that some might
sync mlocked pages when the process which had the page locked dies, especially
if it crashes. Or that some versions of some OSes are simply buggy. It's not
like it's a case that would ever be tested or even noticed if it failed.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!