Re: Page-at-a-time Locking Considerations

"Bruce Momjian"  writes:

>> >> 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.

Another possibility for the CLOG would be having two on-disk copies of it. One
temporary file which would serve purely as the filesystem swap space for the
in-memory pages and would be synced and/or flushed from memory based purely on
memory pressure. The second would be the persistent store which we would write
with copies of pages to when it was time to sync them. On boot we would throw
away the old filesystem back and copy the persistent store.

One downside of using mmap though would be that we would be sacrificing
address space. Regardless of how much of the clog is actually being used we
would be losing address space large enough to cover all the clog we might
need.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning