"Zdenek Kotala" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Zdenek Kotala <[EMAIL PROTECTED]> 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! ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
