On Sun, Sep 11, 2005 at 12:15:01PM -0400, Greg Stark wrote:
> > It'd be nice to get out from under the fixed-size-shmem restriction, but
> > I don't know any very portable way to do that.
>
> Without knowing that part of the code at all it seems to me the logical
> approach would be to make the
Tom Lane wrote:
The thought behind my suggestion was that the current max_fsm_pages
default of 2 pages is enough to track free space in a database of
maybe a few hundred megabytes. The other defaults are sized
appropriately for machines with about that much in main memory. This
doesn't s
Tom Lane <[EMAIL PROTECTED]> writes:
> It'd be nice to get out from under the fixed-size-shmem restriction, but
> I don't know any very portable way to do that.
Without knowing that part of the code at all it seems to me the logical
approach would be to make the fsm steal its pages out of the
Andrew Dunstan wrote:
> And anyway you need to come up with a reasonable alternative for
> packagers, rather than just say "don't do this.". The only one I can
> think of is to run initdb as part of a package postinstall, although
> packagers and especially distro preparers might find that more tha
Robert Treat <[EMAIL PROTECTED]> writes:
> On Thursday 08 September 2005 13:16, Andrew Dunstan wrote:
>> Initdb already
>> has adaptive rules - look at the source - and Tom suggests adding
>> another set for max_fsm_pages. All I'm doing is to suggest that we need
>> to tweak those.
> I'm curious
On Thursday 08 September 2005 13:16, Andrew Dunstan wrote:
> Initdb already
> has adaptive rules - look at the source - and Tom suggests adding
> another set for max_fsm_pages. All I'm doing is to suggest that we need
> to tweak those.
>
I'm curious how this could work... istm its fairly hard to
Jim C. Nasby wrote:
On Thu, Sep 08, 2005 at 03:43:17AM +0200, Peter Eisentraut wrote:
What I would like to see is that initdb would end with saying that the
system is not really tuned and that I should run pg-some-program to
improve that. pg-some-program would analyze my system, ask me a
On Thu, Sep 08, 2005 at 03:43:17AM +0200, Peter Eisentraut wrote:
> What I would like to see is that initdb would end with saying that the
> system is not really tuned and that I should run pg-some-program to
> improve that. pg-some-program would analyze my system, ask me a few
> questions, and
On Thu, Sep 08, 2005 at 08:29:38PM -, Andrew - Supernews wrote:
> On 2005-09-08, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > Andrew - Supernews wrote:
> >> Running initdb behind the scenes is a proven dangerous practice
> >
> > Please elaborate.
>
> Example instance:
> http://archives.post
Dave Page wrote:
perhaps your statement would be more
accurate as:
"Automatically running initdb behind the scenes at system startup is a
proven dangerous practice"
We've distributed hundreds of thousands of copies of pgInstaller which
initdb's behind the scenes and never had any reported pr
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andrew - Supernews
> Sent: 09 September 2005 08:16
> To: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] initdb profiles
>
> On 2005-09-08, Peter Eisentrau
On 2005-09-08, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews wrote:
>> On 2005-09-08, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>> > Andrew - Supernews wrote:
>> >> Running initdb behind the scenes is a proven dangerous practice
>> >
>> > Please elaborate.
>>
>> Example instanc
Andrew - Supernews wrote:
> On 2005-09-08, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > Andrew - Supernews wrote:
> >> Running initdb behind the scenes is a proven dangerous practice
> >
> > Please elaborate.
>
> Example instance:
> http://archives.postgresql.org/pgsql-hackers/2004-12/msg00851.p
On 2005-09-08, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews wrote:
>> Running initdb behind the scenes is a proven dangerous practice
>
> Please elaborate.
Example instance:
http://archives.postgresql.org/pgsql-hackers/2004-12/msg00851.php
More generally, you risk running init
Christian,
> Regarding Configurator, has anything been done yet, or is it in the
> planning stage?
Yes, I have a spreadsheet mapping the values we want to configure for 8.0.
Dave Cramer has done a partial implementation in Java using Drools; the
perl implementation is lagging rather further be
Andrew Dunstan wrote:
> I have a single instance of apache running on this machine. It's not
> doing anything, but even so it's consuming 20% of physical memory. By
> contrast, my 3 postmasters are each consuming 0.5% of memory. All
If I see this right, my Apache, running at default settings, use
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2005-09-08, Tom Lane <[EMAIL PROTECTED]> wrote:
>> initdb is really the wrong place for this anyway, because in many
>> situations (RPM installations for instance) initdb is run behind the
>> scenes with no opportunity for user interaction. We sh
Andrew - Supernews wrote:
> Running initdb behind the scenes is a proven dangerous practice
Please elaborate.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Josh Berkus wrote:
Folks,
Help on the Configurator is actively solicited. I really think this is a
better solution for this problem.
http://www.pgfoundry.org/projects/configurator
I don't agree, for several reasons.
1. Steve has already told us most of his clients just go with the
Folks,
Help on the Configurator is actively solicited. I really think this is a
better solution for this problem.
http://www.pgfoundry.org/projects/configurator
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP
On 2005-09-08, Tom Lane <[EMAIL PROTECTED]> wrote:
> initdb is really the wrong place for this anyway, because in many
> situations (RPM installations for instance) initdb is run behind the
> scenes with no opportunity for user interaction. We should be doing
> our best to remove options from init
Steve Atkins wrote:
These are technically literate customers working for large ISPs, with
significant local sysadmin and DBA support, so the concept is not beyond them.
Yet when I ssh in to one of their servers only about 1 in 3 is running
with anything other than the default postgresql.conf.
On Thu, Sep 08, 2005 at 09:54:59AM +0800, Christopher Kings-Lynne wrote:
> I think we should just do what MySQL does and include:
>
> postgresql.conf
> postgresql-large.conf
> postgresql-huge.conf
I do that, in the package of PG I distribute with my application. I
tell the user that they should
Hello All,
Please allow me to put a disclaimer, I am no serious PG hacker,
but would it be possible to allow for a simple config script to be run
(which would work even via /etc/init.d) which could be used to generate a
config file for initdb, which initdb could read and do its thing ?
Thi
heuristics that initdb could apply. We'd have to let all of these
degrade nicely, so that even if the user select the machine hog setting,
if we find we can only do something like the tiny setting that's what
s/he would get. Also, we might need to have some tolerably portable way
of finding out
Peter Eisentraut wrote:
Andrew Dunstan wrote:
I accept the "run from init.d" argument. So then, is there a case for
increasing the limits that initdb works with, to reflect the steep
rise we have seen in typically available memory at the low end?
There is a compromise that I think w
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> There is a compromise that I think we cannot make. For production
> deployment, shared buffers are typically sized at about 10% to 25% of
> available phyiscal memory. I don't think we want to have a default
> installation of PostgreSQL that takes
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I accept the "run from init.d" argument. So then, is there a case for
increasing the limits that initdb works with, to reflect the steep rise
we have seen in typically available memory at the low end?
I can't see any partic
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> What I would like to see is that initdb would end with saying that the
>> system is not really tuned and that I should run pg-some-program to
>> improve that.
>>
> Perhaps at the end of initdb it would say would you like
> to run the PostgreSQL co
What I would like to see is that initdb would end with saying that the
system is not really tuned and that I should run pg-some-program to
improve that. pg-some-program would analyze my system, ask me a few
questions, and then output a suggested configuration (or apply it right
away). Again
Andrew Dunstan wrote:
> The idea was in fact to allow the user to provide additional
> information to allow initdb to make better guesses than it currently
> does.
There's certainly going to be opposition to making initdb an interactive
tool.
The other problem is that no one has ever managed to
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> All jokes aside, tuning aids are surely needed, but letting initdb guess
> the required profile isn't going to do it.
initdb is really the wrong place for this anyway, because in many
situations (RPM installations for instance) initdb is run behind t
Andrew Dunstan wrote:
> But I wondered if it might not be a good idea to allow
> an option to initdb which would provide a greater possible range of
> settings for max_connections, shared_buffers and so on. For example,
> we might offer a profile which is very conservative for memory bound
That re
33 matches
Mail list logo
