Re: Linux max on shared buffers?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Curt Sampson <cjs(at)cynic(dot)net>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, GB Clark <postgres(at)vsservices(dot)com>, glenebob(at)nwlink(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: Linux max on shared buffers?
Date: 2002-07-20 13:22:09
Message-ID: 20032.1027171329@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Curt Sampson <cjs(at)cynic(dot)net> writes:
> You can always do an msync to force a block out. But I don't think
> you'd ever bother; the transaction log is the only thing for which
> you need to force writes,

This is completely wrong. One of the fatal problems with mmap is that
there's no equivalent of sync(), but only fsync --- a process can only
msync those mmap regions that it has itself got mmap'd. That means that
CHECKPOINT doesn't work, because it has no way to force out all
currently dirty data blocks before placing a "checkpoint done" record
in WAL. You could perhaps get around that with centralized control of
mmap'ing, but at that point you've just got a klugy, not-very-portable
reimplementation of the existing shared buffer manager.

> Sure. For that, you can just mmap an anonymous memory area and share it
> amongst all your processes, or use sysv shared memory.

AFAICS the only thing we'll ever use mmap for is as a direct substitute
for SYSV shared memory on platforms that haven't got it.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message stefan 2002-07-20 13:31:48 Re: COMMIT in PostgreSQL
Previous Message Tom Lane 2002-07-20 13:09:59 Re: Linux max on shared buffers?