Re: WAL & SHM principles

From: Martin Devera <devik(at)cdi(dot)cz>
To: Giles Lean <giles(at)nemeton(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WAL & SHM principles
Date: 2001-03-12 11:26:47
Message-ID: Pine.LNX.4.10.10103121222220.11948-100000@luxik.cdi.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > When you mmap, you don't use write() ! mlock actualy locks page in
> > memory and as long as the page is locked the OS doesn't attempt to
> > store the dirty page. It is intended also for security app to
> > ensure that sensitive data are not written to unsecure storage
> > (hdd). It is definition of mlock so that you can be probably sure
> > with it.
>
> News to me ... can you please point to such a definition? I see no
> reference to such semantics in the mlock() manual page in UNIX98
> (Single Unix Standard, version 2).

sorry, maybe I'm biased toward Linux. The statement above is from Linux's
man page and as I looked into mm code it seems to be right.
I'm not sore about other unices.

> mlock() guarantees that the locked address space is in memory. This
> doesn't imply that updates are not written to the backing file.

yes, probably it depends on OS in question. In Linux kernel the page is
not written when mlocked (but I'm not sure about msync here).

> I would expect an OS that doesn't have a unified buffer cache but
> tries to keep a consistent view for mmap() and read()/write() to
> update the file.

hmm but why to mlock page then ? Only to be sure the page is not wsapped
out ?

regards, devik

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ryan Kirkpatrick 2001-03-12 14:06:08 Vaccuum Failure w/7.1beta4 on Linux/Sparc
Previous Message Karel Zak 2001-03-12 10:11:46 Re: Internationalized dates (was Internationalized error messages)