Re: Re: [PATCHES] A patch for xlog.c - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: Re: [PATCHES] A patch for xlog.c
Date
Msg-id Pine.BSF.4.33.0102260834240.94993-100000@mobile.hub.org
Whole thread Raw
In response to Re: Re: [PATCHES] A patch for xlog.c  (ncm@zembu.com (Nathan Myers))
List pgsql-hackers
On Mon, 26 Feb 2001, Nathan Myers wrote:

> > While I've said before that I don't think it's really necessary for
> > processes that aren't children of the postmaster to access the shared
> > memory, I'm not sure that I want to go over to a mechanism that makes it
> > *impossible* for that to be done.  Especially not if the only motivation
> > is to avoid having to configure the kernel's shared memory settings.
>
> There are enormous advantages to avoiding the need to configure kernel
> settings.  It makes PG a better citizen.  PG is much easier to drop in
> and use if you don't need attention from the IT department.

Is there a reason why Oracle still uses shared memory and hasn't moved to
mmap()?  Are there advantages to it that we aren't seeing, or is oracle
just too much of a mahemouth for that sort of overhaul?  Don't go with the
quick answer either ...

> > Besides, what makes you think there's not a limit on the size of shmem
> > allocatable via mmap()?
>
> I've never seen any mmap limit documented.  Since mmap() is how
> everybody implements shared libraries, such a limit would be equivalent
> to a limit on how much/many shared libraries are used.

There are/will be limits based on how an admin sets his/her per user
datasize limits on their OS ...




pgsql-hackers by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: AW: WAL does not recover gracefully from out-of-disk-sp ace
Next
From: Vince Vielhaber
Date:
Subject: Re: http access to ftp.postgresql.org files