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