Re: Re[2]: Re: [PATCHES] A patch for xlog.c

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: jamexu <jamexu(at)telekbird(dot)com(dot)cn>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re[2]: Re: [PATCHES] A patch for xlog.c
Date: 2001-02-27 03:56:29
Message-ID: Pine.BSF.4.33.0102262354310.339-100000@mobile.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 ...

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-02-27 03:59:33 Re: vacuum analyze fails: ERROR: Unable to locate type oid 2230924 in catalog
Previous Message Bruce Momjian 2001-02-27 03:42:56 Re: Re[2]: Re: [PATCHES] A patch for xlog.c