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

From The Hermit Hacker
Subject Re: Re[2]: Re: [PATCHES] A patch for xlog.c
Date
Msg-id Pine.BSF.4.33.0102262354310.339-100000@mobile.hub.org
Whole thread Raw
In response to Re[2]: Re: [PATCHES] A patch for xlog.c  (The Hermit Hacker <scrappy@hub.org>)
Responses Re: Re[2]: Re: [PATCHES] A patch for xlog.c  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Mon, 26 Feb 2001, Bruce Momjian wrote:

> > > the only problem is because if we need to tune Postermaster to use
> > > large buffer while system havn't so many SYSV shared memory, in many
> > > systemes, we need to recompile OS kernel, this is a small problem to install
> > > PGSQL to product environment.
> >
> > What?  You don't automatically recompile your OS kernel when you build a
> > system in the first place??  First step on any OS install of FreeBSD is to
> > rid myself of the 'extras' that are in the generic kernel, and enable
> > SharedMemory (even if I'm not using PgSQL on that machine) ...
>
> He is saying the machine is already in production.  Suppose he has run
> PostgreSQL for a few months, then needs to increase number of buffers.
> He can't exceed the kernel limit unless he recompiles.

Okay ... same applies to MMAP() though, I had to disappoint ... there are
kernel limits that, at least under FreeBSD, do require a kernel
recompile in order to exceed ... alot of them have been moved (maybe all
now) to sysctl settable values ... but, again, under some of the
commercial OSs, I don't think that anything but (as in Solaris) modifying
something like /etc/system and rebooting will fix ...




pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re[3]: Re: [PATCHES] A patch for xlog.c
Next
From: Tom Lane
Date:
Subject: Re: vacuum analyze fails: ERROR: Unable to locate type oid 2230924 in catalog