On 5-Dec-06, at 4:10 PM, Tom Lane wrote:
Brian Wipf <[EMAIL PROTECTED]> writes:
shared_buffers can now be set as high as shmmax without getting the
error message "could not create shared memory segment...". Now,
however, when shared_buffers are set greater than 279212 a
segmentation fault occurs
Brian Wipf <[EMAIL PROTECTED]> writes:
> shared_buffers can now be set as high as shmmax without getting the
> error message "could not create shared memory segment...". Now,
> however, when shared_buffers are set greater than 279212 a
> segmentation fault occurs on startup of PostgreSQL.
St
I wanted to post a follow up to the list regarding a high
shared_buffers value on OS X 10.4.8.
Thanks to Tom's help we successfully compiled PostgreSQL 8.1.5 using
64-bit on OS X Server 10.4.8 (You can find info. for this on pgports)
shared_buffers can now be set as high as shmmax without g
Am 27.11.2006 um 17:05 schrieb AgentM:
There is a known unfortunate limitation on Darwin for SysV shared
memory which, incidentally, does not afflict POSIX or mmap'd shared
memory.
Hmmm. The article from Chris you have linked does not mention the
size of the mem segment you can allocate.
On Nov 27, 2006, at 2:23 , Brian Wipf wrote:
On 26-Nov-06, at 11:25 PM, Jim C. Nasby wrote:
On Sat, Nov 18, 2006 at 08:13:26PM -0700, Brian Wipf wrote:
It certainly is unfortunate if Guido's right and this is an upper
limit for OS X. The performance benefit of having high
shared_buffers
on
On Mon, Nov 27, 2006 at 07:23:47AM +, Brian Wipf wrote:
> On 26-Nov-06, at 11:25 PM, Jim C. Nasby wrote:
> >On Sat, Nov 18, 2006 at 08:13:26PM -0700, Brian Wipf wrote:
> >>It certainly is unfortunate if Guido's right and this is an upper
> >>limit for OS X. The performance benefit of having hig
Am 27.11.2006 um 08:04 schrieb Guido Neitzer:
But, be aware of another thing here: As far as I have read about 64
Bit applications on G5, these apps are definitely slower than their
32 bit counterparts (I'm currently on the train so I can't be more
precise here without Google ...). Was it s
On 26-Nov-06, at 11:25 PM, Jim C. Nasby wrote:
On Sat, Nov 18, 2006 at 08:13:26PM -0700, Brian Wipf wrote:
It certainly is unfortunate if Guido's right and this is an upper
limit for OS X. The performance benefit of having high shared_buffers
on our mostly read database is remarkable.
Got any
Am 27.11.2006 um 00:25 schrieb Jim C. Nasby:
Got any data about that you can share? People have been wondering
about
cases where drastically increasing shared_buffers makes a difference.
I have tried to compile PostgreSQL as a 64Bit application on my G5
but wasn't successful. But I must ad
Am 27.11.2006 um 04:20 schrieb Brendan Duddridge:
I think the main issue is that we can't seem to get PostgreSQL
compiled for 64 bit on OS X on an Xserve G5. Has anyone done that?
We have 8 GB of RAM on that server, but we can't seem to utilize it
all. At least not for the shared_buffers se
On 27-Nov-06, at 4:04 AM, Tom Lane wrote:
Brendan Duddridge <[EMAIL PROTECTED]> writes:
I think the main issue is that we can't seem to get PostgreSQL
compiled for 64 bit on OS X on an Xserve G5. Has anyone done that?
There is no obvious reason why it would not work, and if anyone has
tried an
Brendan Duddridge <[EMAIL PROTECTED]> writes:
> I think the main issue is that we can't seem to get PostgreSQL
> compiled for 64 bit on OS X on an Xserve G5. Has anyone done that?
There is no obvious reason why it would not work, and if anyone has
tried and failed, they've not bothered to provid
I think the main issue is that we can't seem to get PostgreSQL
compiled for 64 bit on OS X on an Xserve G5. Has anyone done that?
We have 8 GB of RAM on that server, but we can't seem to utilize it
all. At least not for the shared_buffers setting.
Thanks,
__
On Sat, Nov 18, 2006 at 08:13:26PM -0700, Brian Wipf wrote:
> It certainly is unfortunate if Guido's right and this is an upper
> limit for OS X. The performance benefit of having high shared_buffers
> on our mostly read database is remarkable.
Got any data about that you can share? People hav
Am 18.11.2006 um 19:44 schrieb Guido Neitzer:
It might be, that you hit an upper limit in Mac OS X:
[galadriel: memtext ] cug $ ./test
test(291) malloc: *** vm_allocate(size=2363490304) failed (error
code=3)
test(291) malloc: *** error: can't allocate region
test(291) malloc: *** set a break
Am 19.11.2006 um 04:13 schrieb Brian Wipf:
It certainly is unfortunate if Guido's right and this is an upper
limit for OS X. The performance benefit of having high
shared_buffers on our mostly read database is remarkable.
I hate to say that, but if you want best performance out of
Postgre
On 18-Nov-06, at 11:30 AM, Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
On 16-Nov-06, at 7:03 PM, Brian Wipf wrote:
Has anyone else noticed this limitation on OS X? Any ideas on how I
might get shared_buffers higher than 284263?
My guess is something else has taken shared memory a
Hi.
I've sent this out once, but I think it didn't make it through the
mail server ... don't know why. If it is a double post - sorry for it.
Brian Wipf <[EMAIL PROTECTED]> wrote:
> I'm trying to optimize a PostgreSQL 8.1.5 database running on an
> Apple G5 Xserve (dual G5 2.3 GHz w/ 8GB of
Brian Wipf <[EMAIL PROTECTED]> wrote:
> I'm trying to optimize a PostgreSQL 8.1.5 database running on an
> Apple G5 Xserve (dual G5 2.3 GHz w/ 8GB of RAM), running Mac OS X
> 10.4.8 Server.
>
> The queries on the database are mostly reads, and I know a larger
> shared memory allocation will
Dave Cramer <[EMAIL PROTECTED]> writes:
> On 16-Nov-06, at 7:03 PM, Brian Wipf wrote:
>> Has anyone else noticed this limitation on OS X? Any ideas on how I
>> might get shared_buffers higher than 284263?
> My guess is something else has taken shared memory ahead of you. OS X
> seems to be som
Brian,
On 16-Nov-06, at 7:03 PM, Brian Wipf wrote:
I'm trying to optimize a PostgreSQL 8.1.5 database running on an
Apple G5 Xserve (dual G5 2.3 GHz w/ 8GB of RAM), running Mac OS X
10.4.8 Server.
The queries on the database are mostly reads, and I know a larger
shared memory allocation w
21 matches
Mail list logo
