Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
Bruce Momjian <[EMAIL PROTECTED]> writes: > I know it is easy for you, but the number of reports and problems we > hear about shows it is an issue for some. We hear some reports, but not a lot. We have no idea whatever what problems might ensue if we used mmap instead. I'm dubious that SysV shmem creates enough problems to justify replacing it with a solution of essentially unknown portability characteristics... regards, tom lane
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
> > But the mmap() limits are much larger than the SysV limits, aren't they, > > to the point where you would never have to fiddle with the mmap() limits > > to get 100mb of buffers, right? > > Not necessarily ... it depends on the admin of the server ... then again, > I don't consider it a hassle to add a couple of lines to my kernel config > (or /etc/system) and reboot *shrug* to me, its just part of the admin > process ... Are the kernel SysV defaults smaller than the mmap() kernel defaults? I know it is easy for you, but the number of reports and problems we hear about shows it is an issue for some. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
On Mon, 26 Feb 2001, Bruce Momjian wrote: > > 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 ... > > But the mmap() limits are much larger than the SysV limits, aren't they, > to the point where you would never have to fiddle with the mmap() limits > to get 100mb of buffers, right? Not necessarily ... it depends on the admin of the server ... then again, I don't consider it a hassle to add a couple of lines to my kernel config (or /etc/system) and reboot *shrug* to me, its just part of the admin process ...
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
> 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 ... But the mmap() limits are much larger than the SysV limits, aren't they, to the point where you would never have to fiddle with the mmap() limits to get 100mb of buffers, right? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
> > 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. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
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 ...
Re: Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
>> 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. Of course, if you haven't got mmap(), a recompile won't help ... I'd be somewhat more enthusiastic about mmap if I thought we could abandon the SysV shmem support completely, but I don't foresee that happening for a long while yet. regards, tom lane
Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
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) ...
Re[2]: [HACKERS] Re: [PATCHES] A patch for xlog.c
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. -- Best regards, XuYifeng
