Re: Linux max on shared buffers?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, Curt Sampson <cjs(at)cynic(dot)net>, 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:09:59
Message-ID: 19970.1027170599@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> Well, you would have to deal with the fact that writing changes to a mmap()
> is allowed, but you have no guarentee when it will be finally written. Given
> WAL I would suggest using mmap() for reading only and using write() to
> update the file.

This is surely NOT workable; every mmap man page I've looked at is very
clear that you cannot expect predictable behavior if you use both
filesystem and mmap access to the same file. For instance, HP says

It is also unspecified whether write references to a memory region
mapped with MAP_SHARED are visible to processes reading the file and
whether writes to a file are visible to processes that have mapped the
modified portion of that file, except for the effect of msync().

So unless you want to msync after every write I do not think this can fly.

> If in that process the kernel needed
> to throw out another page, who cares?

We do, because we have to control write ordering.

> It is different. I beleive you would still need some form of shared memory
> to co-ordinate write()s.

The whole idea becomes less workable the more we look at it.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

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