On Thu, 24 May 2001, Ryan Mahoney wrote:
> >This is true. You can adjust the value in the /proc/sys/kernel/shmmax
> >file. If you change the value it will be reset when you reboot, so you
> >will need to write a start-up script to always change this value if you
> >want it to be permanent.
On Wed, 10 Jan 2001, Peter Eisentraut wrote:
> Michael J Schout writes:
>
> > We would definately beta test 7.1 beta releases on our test machines if RPMS
> > were made available. However, if rpms are not made available, its unlikely
> > that anyone around here wi
On Fri, 5 Jan 2001, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > I am inclined to wait until a Release Candidate, if we have one this go
> > around, is available before releasing RPM's, but my mind can be
> > changed :-)
>
> Please do make beta RPMs available. Seems to me
On Sun, 24 Dec 2000, Joe Conway wrote:
> Linux
>
> The default shared memory limit (both SHMMAX and SHMALL) is 32 MB in 2.2
> kernels, but it can be changed in the proc file system (without reboot). For
> example, to allow 128 MB:
>
> $ echo 134217728 >/proc/sys/kernel/shmall
> $ echo 134217
Hi.
Ive had a crash in postgresql 7.0.2. Looking at what happened, I actually
suspect that this is a filesystem bug, and not a postgresql bug necessarily,
but I wanted to report it here and see if anyone else had any opinions.
The platform this happened on was linux (redhat 6.2), kernel 2.2.16
On Thu, 19 Oct 2000, Tom Lane wrote:
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> >> SELECT session_data, id
> >> FROM sessions
> >> WHERE id = ?
> >> FOR UPDATE
> >>
> >> I think part of my problem might be that sessions is a view
> >> and not a table,
>
> > Did you create an o
On Tue, 17 Oct 2000, Tom Lane wrote:
> > and we have not had a crash on vacuum since that happened. If this
> > sounds consistent with the problem you think Alfred is having,
>
> Yes, it sure does.
>
> The patch I have applies atop a previous change in the REL7_0_PATCHES
> branch, so what I w
Tom:
I think I may have been seeing this problem as well. We were getting
crashes very often with 7.0.2 during VACUUM's if activity was going
on to our database during the vacuum (even though the activity was
light). Our solution in the meantime was to simply disable the
aplications during a v
