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

From The Hermit Hacker
Subject Re[2]: Re: [PATCHES] A patch for xlog.c
Date
Msg-id Pine.BSF.4.33.0102262259010.339-100000@mobile.hub.org
Whole thread Raw
In response to Re[2]: Re: [PATCHES] A patch for xlog.c  (jamexu <jamexu@telekbird.com.cn>)
Responses Re: Re[2]: Re: [PATCHES] A patch for xlog.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Re[3]: Re: [PATCHES] A patch for xlog.c  (jamexu <jamexu@telekbird.com.cn>)
Re: Re[2]: Re: [PATCHES] A patch for xlog.c  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Tue, 27 Feb 2001, jamexu wrote:

> Hello Tom,
>
> Tuesday, February 27, 2001, 12:23:25 AM, you wrote:
>
> TL> This looks a lot like exchanging the devil we know (SysV shmem) for a
> TL> devil we don't know.  Do I need to remind you about, for example, the
> TL> mmap bugs in early Linux releases?  (I still vividly remember having to
> TL> abandon mmap on a project a few years back that needed to be portable
> TL> to Linux.  Perhaps that colors my opinions here.)  I don't think the
> TL> problems with shmem are sufficiently large to justify venturing into
> TL> a whole new terra incognita of portability issues and kernel bugs.
>
> TL>                         regards, tom lane
>
> 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) ...




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: stuck spinlock
Next
From: Tom Lane
Date:
Subject: Re: Re[2]: Re: [PATCHES] A patch for xlog.c