Brian A. Seklecki wrote:
Thanks to all; with the r1.114 changes, our staff reports the following:
Postgres is able to start with a ~3GB postgresql.conf(5) $shared_buffer
on 8-CURRENT/amd64:
It has recently also been MFC-ed to 7-STABLE :)
(beware of instabilities and debugging in -CURRENT!)
Thanks to all; with the r1.114 changes, our staff reports the following:
Postgres is able to start with a ~3GB postgresql.conf(5) $shared_buffer
on 8-CURRENT/amd64:
PID USERNAME THR PRI NICE SIZERES STATETIME WCPU COMMAND
1036 pgsql 1 440 3013M 79296K select 0:00
On Mon, Feb 23, 2009 at 12:16 PM, Bill Moran wmo...@potentialtech.com wrote:
In response to Christian Peron c...@freebsd.org:
On Mon, Feb 23, 2009 at 11:58:09AM -0800, Garrett Cooper wrote:
[..]
Why isn't the field an unsigned int / size_t? I don't see much value
in having the size
On Tue, 24 Feb 2009, Garrett Cooper wrote:
On Mon, Feb 23, 2009 at 12:16 PM, Bill Moran wmo...@potentialtech.com wrote:
In response to Christian Peron c...@freebsd.org:
On Mon, Feb 23, 2009 at 11:58:09AM -0800, Garrett Cooper wrote:
[..]
Why isn't the field an unsigned int / size_t? I
On Mon, Feb 23, 2009 at 01:08:28PM -0600, Christian Peron wrote:
This issue has come up a number of times. I was looking into fixing this but
I
just have not had the time. The basic issue is our shmid_ds structure:
struct shmid_ds {
struct ipc_perm shm_perm; /* operation
On Wed, 2006-Dec-13 10:50:21 -0500, Bill Moran wrote:
In response to Bill Moran wmoran at collaborativefusion.com:
sysctl kern.ipc.shmmax=22
kern.ipc.shmmax: 21 - -2094967296
Someone was nice enough to file a PR related to this:
This issue has come up a number of times. I was looking into fixing this but I
just have not had the time. The basic issue is our shmid_ds structure:
struct shmid_ds {
struct ipc_perm shm_perm; /* operation permission structure */
int shm_segsz; /* size of
On Feb 23, 2009, at 11:08 AM, Christian Peron wrote:
This issue has come up a number of times. I was looking into fixing
this but I
just have not had the time. The basic issue is our shmid_ds
structure:
struct shmid_ds {
struct ipc_perm shm_perm; /* operation permission
On Mon, Feb 23, 2009 at 11:58:09AM -0800, Garrett Cooper wrote:
[..]
Why isn't the field an unsigned int / size_t? I don't see much value
in having the size be signed...
No idea :) This code long predates me.
___
freebsd-hackers@freebsd.org
In response to Christian Peron c...@freebsd.org:
On Mon, Feb 23, 2009 at 11:58:09AM -0800, Garrett Cooper wrote:
[..]
Why isn't the field an unsigned int / size_t? I don't see much value
in having the size be signed...
No idea :) This code long predates me.
It's that way
In response to Bill Moran [EMAIL PROTECTED]:
[I sent this to questions@ yesterday and have yet to get a response. I
suspect it may be a little more technical than [EMAIL PROTECTED]
uname -a
FreeBSD db00.lab00 6.2-BETA3 FreeBSD 6.2-BETA3 #1: Fri Dec 8 09:27:37 EST
2006 [EMAIL
On Wed, 2006-Dec-13 10:50:21 -0500, Bill Moran wrote:
In response to Bill Moran [EMAIL PROTECTED]:
sysctl kern.ipc.shmmax=22
kern.ipc.shmmax: 21 - -2094967296
Looks like an unsigned 32-bit int. That doesn't seem to scale as well as
would be expected on 64-bit arch (or PAE
[Kris -- are you interested in this or should I trim you from the CC?]
In response to Peter Jeremy [EMAIL PROTECTED]:
On Wed, 2006-Dec-13 10:50:21 -0500, Bill Moran wrote:
In response to Bill Moran [EMAIL PROTECTED]:
sysctl kern.ipc.shmmax=22
kern.ipc.shmmax: 21 -
On Wednesday 13 December 2006 13:34, Peter Jeremy wrote:
On Wed, 2006-Dec-13 10:50:21 -0500, Bill Moran wrote:
In response to Bill Moran [EMAIL PROTECTED]:
sysctl kern.ipc.shmmax=22
kern.ipc.shmmax: 21 - -2094967296
Looks like an unsigned 32-bit int. That doesn't seem
[I sent this to questions@ yesterday and have yet to get a response. I
suspect it may be a little more technical than [EMAIL PROTECTED]
uname -a
FreeBSD db00.lab00 6.2-BETA3 FreeBSD 6.2-BETA3 #1: Fri Dec 8 09:27:37 EST 2006
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/DB-2850-amd64 amd64
15 matches
Mail list logo
