Re: [GENERAL] Postgresql.conf not found

[Andreas Kretschmer]

Hi,


Am 03.11.2017 um 12:51 schrieb Neto pr:

But I'm not finding where the postgresql.conf file is.



you can ask the database, inside psql:

test=# show config_file;
   config_file
-
 /etc/postgresql/10/main/postgresql.conf
(1 Zeile)

test=*#

Regards, Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgresql.conf not found

[Stefan Fercot]

Hi,

You can find the file locations on
https://wiki.debian.org/PostgreSql#File_locations

You should find the configuration in /etc/postgresql/9.6/main.

Kind regards,


On 11/03/2017 12:51 PM, Neto pr wrote:
>
> Hello All
>
> I was trying to install postgresql by this tutorial
> http://powa.readthedocs.io/en/latest/quickstart.html to use the tool
> for bd Powa.
>
> I am use S.O. debian 8 Jessie.
>
> I ran: apt-get install postgresql-9.6 postgresql-client-9.6
> postgresql-contrib-9.6 apt-get install postgresql-9.6-powa
>
> So far so good, the DBMS has gone up and I can create tables etc.
>
> But I'm not finding where the postgresql.conf file is. I tried
> searching using locate postgresql.conf, but can not find, I suspect it
> was not created. I need to add some libraries in the parameter:
> shared_preload_libraries
>
> Has anyone installed postgresql in this way, and could it tell you
> where the postgresql.conf file might be, or another one to configure
> the shared_preload_libraries parameter?
>
> Best Regards Neto
>

-- 
Stefan FERCOT
http://dalibo.com - http://dalibo.org



signature.asc
Description: OpenPGP digital signature

[GENERAL] Postgresql.conf not found

[Neto pr]

Hello All

I was trying to install postgresql by this tutorial
http://powa.readthedocs.io/en/latest/quickstart.html to use the tool for bd
Powa.

I am use S.O. debian 8 Jessie.

I ran: apt-get install postgresql-9.6 postgresql-client-9.6
postgresql-contrib-9.6 apt-get install postgresql-9.6-powa

So far so good, the DBMS has gone up and I can create tables etc.

But I'm not finding where the postgresql.conf file is. I tried searching
using locate postgresql.conf, but can not find, I suspect it was not
created. I need to add some libraries in the parameter:
shared_preload_libraries

Has anyone installed postgresql in this way, and could it tell you where
the postgresql.conf file might be, or another one to configure the
shared_preload_libraries parameter?

Best Regards Neto

[GENERAL] postgresql.conf RH comment, and a systemd RH note

[Karl O. Pinc]

Hi, 

FYI, the RH rpm contains the following comment in postgresql.conf,
which is not in the postgresql.org rpm.  I found it helpful.


@@ -61,11 +61,7 @@
# defaults to 'localhost'; use
'*' for all # (change requires restart)
 #port = 5432   # (change requires restart)
-# Note: In RHEL/Fedora installations, you can't set the port number
here;
-# adjust it in the service file instead.
 max_connections = 100  # (change requires restart)



There is also, by the by, a difference in the way the RHEL
postgresql package has systemd configured.  In RHEL the
postgresql.service file contains a comment that says
to include it and then follow with changes in
/etc/systemd/system/postgresql.service.d/postgresql.service

(The path is what matters, I'm not sure about the
file name.)

But, the "standard RHEL way" to modify the default
systemd config for a service is instead to have files
ending in ".conf", and you don't have to include the original
service file.  So this is the approach to take when installing
the upstream PG rpms.  You make a file, e.g,
/etc/systemd/system/postgresql-9.5.service.d/postgresql-9.5.service.conf

(I'm not sure the file name matters, except for ending
in ".conf".)

According to the docs you should not have to start the
file by including the original service file (in
/usr/lib/systemd/system/), but it does not seem to hurt
to do so.

Anyhow, it makes sense to have the upstream PG rpms
use the "standard RH way" to configure systemd.
But if you're used to coming from the stock RH
rpm the change can lead to confusion.

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] postgreSQL.conf has become zero byte file

[John McKown]

I agree with Adrian. If this is on a Linux system, I'd suggest setting up
"icrond" to monitor that file and at least record who is accessing it. In
addition, I would suggest that said Linux system run with SELinux in
"enforcing" mode. That can stop even "root" from updating something, if it
doesn't have the proper SELinux credentials.

On Mon, Nov 16, 2015 at 11:06 PM, Adrian Klaver 
wrote:

> On 11/16/2015 06:59 PM, M Tarkeshwar Rao wrote:
>
>> Hi All,
>>
>> In our production setup we found new issue as postgreSQL.conf has become
>> zero byte file.
>>
>> After some time we copied that file from some back up, after some time
>> it has again become zero byte.
>>
>> Any clue what is the reason of this behavior.
>>
>
> I tend to doubt that Postgres is zeroing out its own conf file. My guess
> is some other program/script is doing that. If you can narrow down the time
> frame this happening, I would then look for any cron/scheduled jobs that
> are running at the same time.
>
>
>> Regards
>>
>> Tarkeshwar
>>
>>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

Re: [GENERAL] postgreSQL.conf has become zero byte file

[Melvin Davidson]

More importantly, what version of PostgreSQL and what O/S are you working
with.
If this is Ubuntu, you could simply be looking at the wrong postgresql.conf
file.

On Tue, Nov 17, 2015 at 7:33 AM, John McKown 
wrote:

> I agree with Adrian. If this is on a Linux system, I'd suggest setting up
> "icrond" to monitor that file and at least record who is accessing it. In
> addition, I would suggest that said Linux system run with SELinux in
> "enforcing" mode. That can stop even "root" from updating something, if it
> doesn't have the proper SELinux credentials.
>
> On Mon, Nov 16, 2015 at 11:06 PM, Adrian Klaver  > wrote:
>
>> On 11/16/2015 06:59 PM, M Tarkeshwar Rao wrote:
>>
>>> Hi All,
>>>
>>> In our production setup we found new issue as postgreSQL.conf has become
>>> zero byte file.
>>>
>>> After some time we copied that file from some back up, after some time
>>> it has again become zero byte.
>>>
>>> Any clue what is the reason of this behavior.
>>>
>>
>> I tend to doubt that Postgres is zeroing out its own conf file. My guess
>> is some other program/script is doing that. If you can narrow down the time
>> frame this happening, I would then look for any cron/scheduled jobs that
>> are running at the same time.
>>
>>
>>> Regards
>>>
>>> Tarkeshwar
>>>
>>>
>>
>> --
>> Adrian Klaver
>> adrian.kla...@aklaver.com
>>
>>
>> --
>> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-general
>>
>
>
>
> --
>
> Schrodinger's backup: The condition of any backup is unknown until a
> restore is attempted.
>
> Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
>
> He's about as useful as a wax frying pan.
>
> 10 to the 12th power microphones = 1 Megaphone
>
> Maranatha! <><
> John McKown
>



-- 
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

Re: [GENERAL] postgreSQL.conf has become zero byte file

[Adrian Klaver]

On 11/16/2015 06:59 PM, M Tarkeshwar Rao wrote:

Hi All,

In our production setup we found new issue as postgreSQL.conf has become
zero byte file.

After some time we copied that file from some back up, after some time
it has again become zero byte.

Any clue what is the reason of this behavior.


I tend to doubt that Postgres is zeroing out its own conf file. My guess 
is some other program/script is doing that. If you can narrow down the 
time frame this happening, I would then look for any cron/scheduled jobs 
that are running at the same time.




Regards

Tarkeshwar




--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] postgreSQL.conf has become zero byte file

[M Tarkeshwar Rao]

Hi All,

In our production setup we found new issue as postgreSQL.conf has become zero 
byte file.
After some time we copied that file from some back up, after some time it has 
again become zero byte.

Any clue what is the reason of this behavior.

Regards
Tarkeshwar

Re: [GENERAL] postgresql.conf question... CPU spikes

[Bala Venkat]

As Andy mentioned. After tuning a query, every thing settled in . Now the
cpu utilization has come down a lot..

Thanks a lot for the help. I will certainly use the tool, pg_top

kind regards


On Fri, Apr 11, 2014 at 12:35 AM, Venkata Balaji Nagothi
vbn...@gmail.comwrote:


 On Thu, Apr 10, 2014 at 12:43 AM, Bala Venkat akpg...@gmail.com wrote:

 Hi all -

We are running postgres 9.0 ( 32 bit ) + postgis 1.5.2 on Solaris
 Sparc M5000 with 64GB .  Recently we are getting CPU utilitzation to 99% .

 In the config file


 shared_buffers=2GB.
 work_mem = 128MB
 effective_cache_size=48GB
 maintaince_work_mem= 500MB
 max_connections = 300

 When the CPU spikes happens, when I look at the pg_stat_activity log, the
 queries where current_query not like '%IDLE%' are between 100-110.

 Do you think , I have to reduce the effective_cache and work_mem for this?


 What does the load average say ? What about memory usage and disk IO ?

 Best way to look at CPU spikes issue is through top or equivalent
 utility which helps us know the PIDs for top resource consuming processes
 and the processes / sessions info using the same PIDs can be pulled in from
 pg_stat_activity.

 Another best way - which i felt is the best tool is - pg_top. pg_top is an
 excellent tool which help us identify the top resource consuming queries
 responsible for high CPU consumption or high DISK IO.

 Once you identify resource consuming processes or queries, things can be
 taken from there.

 Regards,

 Venkata Balaji N
 Fujitsu Australia

Re: [GENERAL] postgresql.conf question... CPU spikes

[Venkata Balaji Nagothi]

On Thu, Apr 10, 2014 at 12:43 AM, Bala Venkat akpg...@gmail.com wrote:

 Hi all -

We are running postgres 9.0 ( 32 bit ) + postgis 1.5.2 on Solaris
 Sparc M5000 with 64GB .  Recently we are getting CPU utilitzation to 99% .

 In the config file


 shared_buffers=2GB.
 work_mem = 128MB
 effective_cache_size=48GB
 maintaince_work_mem= 500MB
 max_connections = 300

 When the CPU spikes happens, when I look at the pg_stat_activity log, the
 queries where current_query not like '%IDLE%' are between 100-110.

 Do you think , I have to reduce the effective_cache and work_mem for this?


What does the load average say ? What about memory usage and disk IO ?

Best way to look at CPU spikes issue is through top or equivalent utility
which helps us know the PIDs for top resource consuming processes and the
processes / sessions info using the same PIDs can be pulled in from
pg_stat_activity.

Another best way - which i felt is the best tool is - pg_top. pg_top is an
excellent tool which help us identify the top resource consuming queries
responsible for high CPU consumption or high DISK IO.

Once you identify resource consuming processes or queries, things can be
taken from there.

Regards,

Venkata Balaji N
Fujitsu Australia

[GENERAL] postgresql.conf question... CPU spikes

[Bala Venkat]

Hi all -

   We are running postgres 9.0 ( 32 bit ) + postgis 1.5.2 on Solaris
Sparc M5000 with 64GB .  Recently we are getting CPU utilitzation to 99% .

In the config file


shared_buffers=2GB.
work_mem = 128MB
effective_cache_size=48GB
maintaince_work_mem= 500MB
max_connections = 300

When the CPU spikes happens, when I look at the pg_stat_activity log, the
queries where current_query not like '%IDLE%' are between 100-110.

Do you think , I have to reduce the effective_cache and work_mem for this?

Thanks for your help.

Re: [GENERAL] postgresql.conf question... CPU spikes

[Andy Colson]

On 04/09/2014 09:43 AM, Bala Venkat wrote:

Hi all -

We are running postgres 9.0 ( 32 bit ) + postgis 1.5.2 on Solaris Sparc 
M5000 with 64GB .  Recently we are getting CPU utilitzation to 99% .

In the config file


shared_buffers=2GB.
work_mem = 128MB
effective_cache_size=48GB
maintaince_work_mem= 500MB
max_connections = 300

When the CPU spikes happens, when I look at the pg_stat_activity log, the queries 
where current_query not like '%IDLE%' are between 100-110.

Do you think , I have to reduce the effective_cache and work_mem for this?

Thanks for your help.


My guess would be you are running queries that dont use indexes, so its table 
scanning, and the tables all fit in memory.

You should run explain analyze on some of your queries and make sure you have 
good indexes.

You could also log slow queries, which might give some hints.


Do you think , I have to reduce the effective_cache and work_mem for this?


I would doubt it.

-Andy


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] postgresql.conf error

[Jayadevan M]

Hi,

Which is the quickest way to troubleshot the message 

LOG:  configuration file /postgresql.conf contains errors;
unaffected changes were applied ?

I made a couple of changes a few days ago, and did not reload Today I made
some more changes and did a pg_ctl reload.

Is there an option to test the configuration file for errors, after making
changes?

Regards,
Jayadevan

Re: [GENERAL] postgresql.conf error

[Tom Lane]

Jayadevan M maymala.jayade...@gmail.com writes:
 Which is the quickest way to troubleshot the message 
 LOG:  configuration file /postgresql.conf contains errors;
 unaffected changes were applied ?

There should be log message(s) before that one complaining about the
specific problems.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] postgresql.conf error

[Jayadevan M]

Thanks. This is what I have. May be it is not really an error?

2013-10-18 12:23:54.996 IST,,,8855,,523c23ea.2297,20,,2013-09-20 16:01:06
IST,,0,LOG,0,received SIGHUP, reloading configuration files,
2013-10-18 12:23:54.996 IST,,,8855,,523c23ea.2297,21,,2013-09-20 16:01:06
IST,,0,LOG,55P02,parameter superuser_reserved_connections cannot be
changed without restarting the server,
2013-10-18 12:23:54.997 IST,,,8855,,523c23ea.2297,22,,2013-09-20 16:01:06
IST,,0,LOG,F,configuration file
/pgdata/prod/data_93/postgresql.conf contains errors; unaffected
changes were applied,



On Fri, Oct 18, 2013 at 1:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:

 Jayadevan M maymala.jayade...@gmail.com writes:
  Which is the quickest way to troubleshot the message 
  LOG:  configuration file /postgresql.conf contains errors;
  unaffected changes were applied ?

 There should be log message(s) before that one complaining about the
 specific problems.

 regards, tom lane

Re: [GENERAL] postgresql.conf error

[Raghu Ram]

On Fri, Oct 18, 2013 at 2:01 PM, Jayadevan M maymala.jayade...@gmail.comwrote:

 Thanks. This is what I have. May be it is not really an error?

 2013-10-18 12:23:54.996 IST,,,8855,,523c23ea.2297,20,,2013-09-20 16:01:06
 IST,,0,LOG,0,received SIGHUP, reloading configuration files,
 2013-10-18 12:23:54.996 IST,,,8855,,523c23ea.2297,21,,2013-09-20 16:01:06
 IST,,0,LOG,55P02,parameter superuser_reserved_connections cannot be
 changed without restarting the server,
 2013-10-18 12:23:54.997 IST,,,8855,,523c23ea.2297,22,,2013-09-20 16:01:06
 IST,,0,LOG,F,configuration file
 /pgdata/prod/data_93/postgresql.conf contains errors; unaffected
 changes were applied,


To effect new changes related to superuser_reserved_connections
parameters in Postgresql.conf file requires RESTART of the PostgreSQL
Service.

Thanks  Regards
Raghu Ram

[GENERAL] postgresql.conf evaluation of duplicate keys

[Martin Gerdes]

I've got a question relating to how the postgres configuration is parsed:

If I write into the following into postgresql.conf:
shared_buffers = 24MB
shared_buffers = 32MB

and start up postgres, the command 'show shared_buffers;' answers 
'32MB'. That means the later value in the configuration file took 
precedence. Which is great and what I would expect.
Now the question: Is this just a happy accident and could change at any 
time, or is this documented and guaranteed behaviour (and if so, can you 
point me to the relevant documentation)? I tried to search for it, but 
my google foo is just not strong enough :-)


Answer to the (probably) inevitable question: What are you trying to 
achieve? :
I am trying to define a set of defaults, which will get deployed to 
multiple servers, and will be overwritten automatically. Yet I also want 
to have the option to change individual parameters on one server. So I 
want to introduce a line #==do not modify above this line==. 
Everything above the line will be replaced, everything below it left 
untouched.
So if postgres is actually also parsing a file postgresql.local whose 
values are guaranteed to take precedence over postgresql.conf, that 
would solve my problem as well.


Many thanks in advance!

Martin


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] postgresql.conf evaluation of duplicate keys

[David Kerr]

On 03/21/2012 07:02 AM, Martin Gerdes wrote:

I've got a question relating to how the postgres configuration is parsed:

If I write into the following into postgresql.conf:
shared_buffers = 24MB
shared_buffers = 32MB

and start up postgres, the command 'show shared_buffers;' answers 
'32MB'. That means the later value in the configuration file took 
precedence. Which is great and what I would expect.
Now the question: Is this just a happy accident and could change at 
any time, or is this documented and guaranteed behaviour (and if so, 
can you point me to the relevant documentation)? I tried to search for 
it, but my google foo is just not strong enough :-)


Answer to the (probably) inevitable question: What are you trying to 
achieve? :
I am trying to define a set of defaults, which will get deployed to 
multiple servers, and will be overwritten automatically. Yet I also 
want to have the option to change individual parameters on one server. 
So I want to introduce a line #==do not modify above this line==. 
Everything above the line will be replaced, everything below it left 
untouched.
So if postgres is actually also parsing a file postgresql.local 
whose values are guaranteed to take precedence over postgresql.conf, 
that would solve my problem as well.


Many thanks in advance!

Martin


I'm doing basically the same thing except my postgresql.conf includes 
a server.conf and the server.conf would contain any overrides.


I am counting on the behavior you mentioned above to allow this to 
happen as well.


Dave

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Postgresql.conf - What is the default value for log_min_message?

[Wang, Mary Y]

Hi,
I've two questions.
(1) I updated logging_collector = true in postgresql.conf because I want to 
rotate the logs.  I'd also like to set the log_min_message to 'debug5' so that 
I can better debug the code for now and will change it back to a lower level 
when it's in production.  I'm looking at the postgresql.conf file and the 
log_min_message is commented out.  So what is the default?
(2) At PgEast2010, I heard someone mentioned about putting the log file to 
another server?  Is that true?  If so, why?  I might have heard it wrong.

Thanks in advance.
Mary




-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgresql.conf - What is the default value for log_min_message?

[Greg Smith]

Wang, Mary Y wrote:

(1) I updated logging_collector = true in postgresql.conf because I want to 
rotate the logs.  I'd also like to set the log_min_message to 'debug5' so that 
I can better debug the code for now and will change it back to a lower level 
when it's in production.  I'm looking at the postgresql.conf file and the 
log_min_message is commented out.  So what is the default?
  


I'll answer that in a more general way so you can figure this out 
yourself the next time:  you can find out what the current value of a 
setting is by either doing:


show log_min_messages;

Or:

select name,setting,boot_val from pg_settings where name='log_min_messages';

If you're not using 8.4 or later you'll have to leave boot_val (which is 
the server default when it starts) out of that query.


By the way:  'debug2' is normally plenty of debugging information.  The 
lower levels start debugging the server internals, rather than anything 
you're likely to be worried about.



(2) At PgEast2010, I heard someone mentioned about putting the log file to 
another server?  Is that true?  If so, why?  I might have heard it wrong.
  


If you use syslog logging, you can use the OS to forward the logs to 
another system.  You might also use a remote filesystem mounting 
approach and write the log files to there.  Those are the two main 
options for putting the log files somewhere else, both of which have 
their own problems.  syslog loses messages sometimes, and remote access 
puts you in a position where a network outage can impact the local 
server which is never a good place to be.


--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com   www.2ndQuadrant.us


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Postgresql.conf

[Laurent Manchon]

Hi,

I have a slow response of my PostgreSQL database 7.4 using this query below
on a table with 80 rows:

select count(*)from tbl;

PostgreSQL return result in 28 sec every time.
although MS-SQL return result in 0.02 sec every time.

My server is a DELL PowerEdge 2600 with bi-processor Xeon at 3.2 Ghz
with 3GBytes RAM


My PostgreSQL Conf is
*
log_connections = yes
syslog = 2
effective_cache_size = 5
sort_mem = 1
max_connections = 200
shared_buffers = 3000
vacuum_mem = 32000
wal_buffers = 8
max_fsm_pages = 2000
max_fsm_relations = 100

Can you tell me is there a way to increase performance ?

Thank you





+-+
| Laurent Manchon |
| Email: [EMAIL PROTECTED] |
+-+

Re: [GENERAL] Postgresql.conf

[A. Kretschmer]

am  Tue, dem 23.01.2007, um 12:11:40 +0100 mailte Laurent Manchon folgendes:
 Hi,
 
 I have a slow response of my PostgreSQL database 7.4 using this query below
 on a table with 80 rows:
 
 select count(*)from tbl;

How often do you want to ask the very same question?
You have enough answers, read this!


Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: - Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] Postgresql.conf

[Brandon Aiken]

Out of curiosity, has the COUNT(*) with no WHERE clause slowness been
fixed in 8.x?  Or is it still an issue of there's no solution that
won't harm aggregates with WHERE clauses?

--
Brandon Aiken
CS/IT Systems Engineer

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of A. Kretschmer
Sent: Tuesday, January 23, 2007 6:17 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Postgresql.conf

am  Tue, dem 23.01.2007, um 12:11:40 +0100 mailte Laurent Manchon
folgendes:
 Hi,
 
 I have a slow response of my PostgreSQL database 7.4 using this query
below
 on a table with 80 rows:
 
 select count(*)from tbl;

How often do you want to ask the very same question?
You have enough answers, read this!


Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: - Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match



** LEGAL DISCLAIMER **
Statements made in this email may or may not reflect the views and opinions of 
Wineman Technology, Inc.
This E-mail message and any attachments may contain legally privileged, 
confidential or proprietary information. If you are not the intended 
recipient(s), or the employee or agent responsible for delivery of this message 
to the intended recipient(s), you are hereby notified that any dissemination, 
distribution or copying of this E-mail message is strictly prohibited. If you 
have received this message in error, please immediately notify the sender and 
delete this E-mail message from your computer.

QS Disclaimer Demo. Copyright (C) Pa-software.
Visit www.pa-software.com for more information.


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] Postgresql.conf

[A. Kretschmer]

am  Tue, dem 23.01.2007, um 10:12:13 -0500 mailte Brandon Aiken folgendes:
 Out of curiosity, has the COUNT(*) with no WHERE clause slowness been
 fixed in 8.x?  Or is it still an issue of there's no solution that
 won't harm aggregates with WHERE clauses?

I will try it:

scholl=# \timing
Timing is on.
scholl=# select count(1) from bde_meldungen ;
  count
-
 1813210
(1 row)

Time: 1925.471 ms
scholl=*# select count(1) from bde_meldungen where datum = 
current_date-'1day'::interval;
 count
---
  2694
(1 row)

Time: 5.670 ms


Btw: yes, the table has more rows than the table from the origin poster
and the count(1) is much faster. Perhaps he should show us an 'explain
analyse'. My guess: many dead tuples.



Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: - Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] Postgresql.conf

[Tino Wildenhain]

A. Kretschmer schrieb:

am  Tue, dem 23.01.2007, um 10:12:13 -0500 mailte Brandon Aiken folgendes:

Out of curiosity, has the COUNT(*) with no WHERE clause slowness been
fixed in 8.x?  Or is it still an issue of there's no solution that
won't harm aggregates with WHERE clauses?


I will try it:

scholl=# \timing
Timing is on.
scholl=# select count(1) from bde_meldungen ;


^^
 k localized object names ;)))

Tino

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [GENERAL] Postgresql.conf

[Bruno Wolff III]

On Tue, Jan 23, 2007 at 10:12:13 -0500,
  Brandon Aiken [EMAIL PROTECTED] wrote:
 Out of curiosity, has the COUNT(*) with no WHERE clause slowness been
 fixed in 8.x?  Or is it still an issue of there's no solution that
 won't harm aggregates with WHERE clauses?

Probably not in the sense that you mean.

The underlying problem is that in MVCC there is no single global answer
to the question and the pain of maintaining the mutliple answers outweighs
the cost of doing so in normal usage.

People that need to run count(*) queries a lot may want to make a different
trade off and some ways of maintaining counts are covered in the archives.

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [GENERAL] Postgresql.conf

[Jeremy Haile]

But there are ways that we could optimize count(*) queries for specific
circumstances right?  Obviously this isn't trivial, but I think it would
be nice if we could maintain a number of rows count that could be used
when performing a count(*) on the whole table (no where clause).   

I don't know if the overhead of keeping track of that number is worth
the benefits - but I know that querying for the number of rows in a
table is a common need and other RDBMSs do optimize for that special
case.

On Tue, 23 Jan 2007 12:53:43 -0600, Bruno Wolff III [EMAIL PROTECTED]
said:
 On Tue, Jan 23, 2007 at 10:12:13 -0500,
   Brandon Aiken [EMAIL PROTECTED] wrote:
  Out of curiosity, has the COUNT(*) with no WHERE clause slowness been
  fixed in 8.x?  Or is it still an issue of there's no solution that
  won't harm aggregates with WHERE clauses?
 
 Probably not in the sense that you mean.
 
 The underlying problem is that in MVCC there is no single global answer
 to the question and the pain of maintaining the mutliple answers
 outweighs
 the cost of doing so in normal usage.
 
 People that need to run count(*) queries a lot may want to make a
 different
 trade off and some ways of maintaining counts are covered in the
 archives.
 
 ---(end of broadcast)---
 TIP 3: Have you checked our extensive FAQ?
 
http://www.postgresql.org/docs/faq

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/

Re: [GENERAL] Postgresql.conf

[Merlin Moncure]

On 1/23/07, Laurent Manchon [EMAIL PROTECTED] wrote:

 Hi,

 I have a slow response of my PostgreSQL database 7.4 using this query below
 on a table with 80 rows:

 select count(*)from tbl;

 PostgreSQL return result in 28 sec every time.
 although MS-SQL return result in 0.02 sec every time.

 My server is a DELL PowerEdge 2600 with bi-processor Xeon at 3.2 Ghz
 with 3GBytes RAM


if you need a fast approximate answer (up to date as of last analyze),
you can do something like:

select reltuples from pg_class where relname = 'tbl' and relkind = 'r';

if you need a fast exact answer, you need to write a trigger.

merlin

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] Postgresql.conf

[Martijn van Oosterhout]

On Tue, Jan 23, 2007 at 02:15:23PM -0500, Jeremy Haile wrote:
 But there are ways that we could optimize count(*) queries for specific
 circumstances right?  Obviously this isn't trivial, but I think it would
 be nice if we could maintain a number of rows count that could be used
 when performing a count(*) on the whole table (no where clause).   

Not really. SQL has fairly strict specifications to the answer to that
query and anything that would optimise it comes at a not inconsiderable
cost.

If you don't care about an exact answer, you can find a number of
methods in the archives.

 I don't know if the overhead of keeping track of that number is worth
 the benefits - but I know that querying for the number of rows in a
 table is a common need and other RDBMSs do optimize for that special
 case.

It's not just keeping track of the number of rows. It keeping track of the
number of rows for each currently executing transaction, since each
transaction could get a different answer. So any accurate method is
going to be tracking the number of tuples even for transactions that don't
want to know. For people who really want to spend the overhead, you can
make a working system. But most people can live with estimates...

Have a nice day,
-- 
Martijn van Oosterhout   kleptog@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature

Re: [GENERAL] Postgresql.conf

[Bruno Wolff III]

On Tue, Jan 23, 2007 at 14:15:23 -0500,
  Jeremy Haile [EMAIL PROTECTED] wrote:
 But there are ways that we could optimize count(*) queries for specific
 circumstances right?  Obviously this isn't trivial, but I think it would
 be nice if we could maintain a number of rows count that could be used
 when performing a count(*) on the whole table (no where clause).   

People can already do that. How to do it right (to avoid update contention)
is even described in the mailing list archives. There just isn't a nice
contrib or pgfoundry project to wrap it up for them. Of course if there was
people might install the project even though there was a net loss in
performance for them.

 I don't know if the overhead of keeping track of that number is worth
 the benefits - but I know that querying for the number of rows in a
 table is a common need and other RDBMSs do optimize for that special
 case.

That is debatable. Certainly a lot of people run adhoc unconstrained count(*)
queries. Whether they normally need exact counts or whether the number of such
queries is large enough compared to other queries being done to be considered
common is another matter.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] Postgresql.conf

[Benjamin Smith]

Andreas, 

Would you mind explaining what you mean by localized object names and why it 
might be bad? Or where I might go to learn more? 

Thanks,

-Ben 

On Tuesday 23 January 2007 07:38, Tino Wildenhain wrote:
 A. Kretschmer schrieb:
  am  Tue, dem 23.01.2007, um 10:12:13 -0500 mailte Brandon Aiken folgendes:
  Out of curiosity, has the COUNT(*) with no WHERE clause slowness been
  fixed in 8.x?  Or is it still an issue of there's no solution that
  won't harm aggregates with WHERE clauses?
  
  I will try it:
  
  scholl=# \timing
  Timing is on.
  scholl=# select count(1) from bde_meldungen ;
 
  ^^
   k localized object names ;)))
 
 Tino
 
 ---(end of broadcast)---
 TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
 
 -- 
 This message has been scanned for viruses and
 dangerous content by MailScanner, and is
 believed to be clean.
 

-- 
I kept looking around for somebody to solve the problem. 
Then I realized I am somebody 
   -Anonymous

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] Postgresql.conf

[A. Kretschmer]

am  Tue, dem 23.01.2007, um 20:48:28 -0800 mailte Benjamin Smith folgendes:
 Andreas, 
 
 Would you mind explaining what you mean by localized object names and why 
 it 
 might be bad? Or where I might go to learn more? 
 
 Thanks,

Tino wrote this ;-)
Btw.: Fullquote below make its harder to understand what do you meen.


 
 -Ben 
 
 On Tuesday 23 January 2007 07:38, Tino Wildenhain wrote:
  A. Kretschmer schrieb:
   am  Tue, dem 23.01.2007, um 10:12:13 -0500 mailte Brandon Aiken folgendes:
   Out of curiosity, has the COUNT(*) with no WHERE clause slowness been
   fixed in 8.x?  Or is it still an issue of there's no solution that
   won't harm aggregates with WHERE clauses?
   
   I will try it:
   
   scholl=# \timing
   Timing is on.
   scholl=# select count(1) from bde_meldungen ;
  
   ^^
k localized object names ;)))
  
  Tino

As I said, Tino wrote this, ask him, not me.
(But I think I know what he means...)



Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: - Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] postgresql.conf shared buffers

[Harald Armin Massa]

Jim, list,from your link:ttp://www.varlena.com/GeneralBits/Tidbits/annotated_conf_e.html 
I quote:As a rule of thumb,
observe shared memory usage of PostgreSQL with
tools like ipcs and determine the setting. Remember that this is
only half the story. You also need to set effective_cache_size so
that  postgreSQL will use available memory optimally.and add the question (not necessarily to you): -what is the best way to obsere shared memory usage on win32?
- which memory-size should be taken for effective_cache_size on windows servers with multpile purposes (i.e.: more then PostgreSQL running on them)Available are (propable ones): physical memory, system cache, available memory (depends on system load)
Harald-- GHUM Harald Massapersuadere et programmareHarald Armin MassaReinsburgstraße 202b70197 Stuttgart0173/9409607-Python: the only language with more web frameworks than keywords.

Re: [GENERAL] postgresql.conf shared buffers

[Alexander Staubo]

On Oct 11, 2006, at 03:34 , Jim C. Nasby wrote:


And increase estimated_cache_size to something close
to how much memory you have.


That would be effective_cache_size.

Alexander.

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [GENERAL] postgresql.conf shared buffers

[Jim C. Nasby]

Please take a look at
http://www.varlena.com/GeneralBits/Tidbits/annotated_conf_e.html first.

In a nutshell, set shared_buffers to between 10% and 25% of your memory
if it's a server. And increase estimated_cache_size to something close
to how much memory you have.

On Tue, Oct 03, 2006 at 07:50:42PM +0530, km wrote:
 Hi all,
 
 - What does the shared_buffers setting do ?
 - Does it mean that that the postgres cannot access most of the physical RAM 
 but limited to the memory setting (shared_buffers) specified ?
 - How do i relate and set max_connections and shared_buffers?
 - Is there a thumb rule to determine shared_buffers from max connections ? 
 - I see , by default max_connections set to 100 and shared_buffers to 1000 - 
 does 1000 mean 1000 bytes or KB ?
 - Also postgres will not start if the shared_buffers value exceeds the kernel 
 setting of SHMMAX. do i need to recompile the kernel to increase this value ? 
 or is there any workaround ? 
 
 tia,
 regards,
 KM
 
 ---(end of broadcast)---
 TIP 5: don't forget to increase your free space map settings
 

-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

[GENERAL] postgresql.conf shared buffers

[km]

Hi all,

- What does the shared_buffers setting do ?
- Does it mean that that the postgres cannot access most of the physical RAM 
but limited to the memory setting (shared_buffers) specified ?
- How do i relate and set max_connections and shared_buffers?
- Is there a thumb rule to determine shared_buffers from max connections ? 
- I see , by default max_connections set to 100 and shared_buffers to 1000 - 
does 1000 mean 1000 bytes or KB ?
- Also postgres will not start if the shared_buffers value exceeds the kernel 
setting of SHMMAX. do i need to recompile the kernel to increase this value ? 
or is there any workaround ? 

tia,
regards,
KM

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

[GENERAL] postgresql.conf listen_addresses causing connection problems

[David Bernal]

I recently have been attempting to get my install of postgresql 8.1
(running Win XP as OS) to listen on both 127.0.0.1 and my IP address,
192.168.0.100 (inside my network, obviously.) As such, I tried first
setting listen_addresses = '192.168.0.100, localhost'

With it like that, when I try to connect to the server using localhost
(I've tried this on a couple different clients) I get an error. If,
for example, I run psql -U user -d base, I get
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

Now, if I try again, this time with psql -h 192.168.0.100 -U user -d
base, it simply hangs, I don't even get a password prompt. Just for
fun, I let this sit for about 30 minutes, and it still did nothing. I
also checked the various logs I know of, and found nothing.

As a work around, I have tried setting
listen_addresses='192.168.0.100', however then I get an error about
half of the time, and it works normally half the time.

Setting listen_addresses='localhost' works just dandy, but then I
can't access the 'base except from home, and that's no good either.

Now, I did make some changes to my router recently, that I haven't
looked into yet, however, since this is all happening inside the
network, and mostly on the same machine as pgsql, I don't think that
would be it (correct me if I'm wrong.)

Any ideas? I'm fairly baffled, but then I'm a newbie.

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] postgresql.conf listen_addresses causing connection problems

[Ian Harding]

On 3/29/06, David Bernal [EMAIL PROTECTED] wrote:
 I recently have been attempting to get my install of postgresql 8.1
 (running Win XP as OS) to listen on both 127.0.0.1 and my IP address,
 192.168.0.100 (inside my network, obviously.) As such, I tried first
 setting listen_addresses = '192.168.0.100, localhost'

Try * (wildcard) and see what happens.  It should either work or not
work, not work 'sometimes' so I think there must be something else
involved.  If pg_hba.conf is set up right, and listen address is *
then you have the network to look at.

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [GENERAL] postgresql.conf listen_addresses causing connection problems

[Tom Lane]

David Bernal [EMAIL PROTECTED] writes:
 I recently have been attempting to get my install of postgresql 8.1
 (running Win XP as OS) to listen on both 127.0.0.1 and my IP address,
 192.168.0.100 (inside my network, obviously.) As such, I tried first
 setting listen_addresses = '192.168.0.100, localhost'

By 8.1 do you really mean 8.1.0?  If so, you might try updating to
the latest subrelease (currently 8.1.3).  This problem doesn't offhand
seem to match any of the bug fixes I see in the CVS logs, but there have
been a number of Windows-specific fixes and maybe one of them explains
it.

 With it like that, when I try to connect to the server using localhost
 (I've tried this on a couple different clients) I get an error. If,
 for example, I run psql -U user -d base, I get
 psql: server closed the connection unexpectedly
 This probably means the server terminated abnormally
 before or while processing the request.

This should certainly leave some trace in the postmaster log file.
If you don't know where the log output is going, find out ;-)

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [GENERAL] postgresql.conf listen_addresses causing connection problems

[Adrian Klaver]

On Wednesday 29 March 2006 02:59 am, David Bernal wrote:


 Any ideas? I'm fairly baffled, but then I'm a newbie.

Just a thought, did you restart the server after making the changes?
From the  Postgres docs-
...This parameter can only be set at server start.

-- 
Adrian Klaver   
[EMAIL PROTECTED]

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [GENERAL] postgresql.conf listen_addresses causing connection problems

[David Bernal]

 Try * (wildcard) and see what happens.  It should either work or not
 work, not work 'sometimes' so I think there must be something else
 involved.  If pg_hba.conf is set up right, and listen address is *
 then you have the network to look at.

I actually also did try '*', and it actually did sometimes work and
sometimes not. Most of the time it wouldn't work, but occaisonally it
did.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] postgresql.conf listen_addresses causing connection problems

[David Bernal]

 Just a thought, did you restart the server after making the changes?
 From the  Postgres docs-
 ...This parameter can only be set at server start.

Sure did, each and every time.

On 3/29/06, Adrian Klaver [EMAIL PROTECTED] wrote:
 On Wednesday 29 March 2006 02:59 am, David Bernal wrote:

 
  Any ideas? I'm fairly baffled, but then I'm a newbie.
 
 Just a thought, did you restart the server after making the changes?
 From the  Postgres docs-
 ...This parameter can only be set at server start.

 --
 Adrian Klaver
 [EMAIL PROTECTED]


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] postgresql.conf listen_addresses causing connection problems

[David Bernal]

 By 8.1 do you really mean 8.1.0?  If so, you might try updating to
 the latest subrelease (currently 8.1.3).  This problem doesn't offhand
 seem to match any of the bug fixes I see in the CVS logs, but there have
 been a number of Windows-specific fixes and maybe one of them explains
 it.
Yeah, sorry it is 8.1.0. If it comes to that, I will try the CVS
version, but I'm kind of leaning towards this being a network problem,
so I want to investigate that first.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

[GENERAL] postgresql.conf value need advice

[marcelo Cortez]

folks

  what is preferible value for
stats_reset_on_server_start ?

what is default value?

 best regards 
  MDC

__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [GENERAL] postgresql.conf value need advice

[Ragnar Hafstað]

On Wed, 2005-08-03 at 13:30 -0300, marcelo Cortez wrote:
 folks
 
   what is preferible value for
 stats_reset_on_server_start ?

depends on whether you want stats to be accumulated for longer periods
than between restarts. I imagine that 'on' is what most people need.

in any case, you can reset stats with the function pg_stat_reset()

 what is default value?
the default is 'on'

see  
http://www.postgresql.org/docs/8.0/static/runtime-config.html#RUNTIME-CONFIG-STATISTICS

gnari



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [GENERAL] postgresql.conf - add_missing_from

[Niederland]

Yes I removed the comment...

Tail end of postgresql.conf..

#---
# VERSION/PLATFORM COMPATIBILITY
#---

# - Previous Postgres Versions -

# do not allow the database engine to change the from clause
add_missing_from = false
#regex_flavor = advanced# advanced, extended, or basic
#sql_inheritance = true
#default_with_oids = true
# - Other Platforms  Clients -

#transform_null_equals = false


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [GENERAL] postgresql.conf - add_missing_from

[Bruce Momjian]

Niederland wrote:
 postgres does not seem to pick up
 the following parameter in the postgresql.conf
 
 add_missing_from = false
 
 Setting the parameter via psql, functions properly
 SET add_missing_from TO FALSE
 
 Using: winxp, Postges 8.0
 (note: I did restart the service after updating the parameters in
 postgresql.conf)

It works on my BSD system using 8.0 with postgresql.conf of:

add_missing_from = false

Did you remove the comment?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[GENERAL] postgresql.conf - add_missing_from

[Niederland]

postgres does not seem to pick up
the following parameter in the postgresql.conf

add_missing_from = false

Setting the parameter via psql, functions properly
SET add_missing_from TO FALSE

Using: winxp, Postges 8.0
(note: I did restart the service after updating the parameters in
postgresql.conf)


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

[GENERAL] postgresql.conf

[John Cunningham]

Hey Guys,

I am setting up a new dedicated Postgres server, and will serve about
60 databases to a web site serving 250,000 people at the rate of about
20,000 a day.  That may all be irrellevent though for the purposes of
this conversation.

The main thing about the application is that we're talking about lots
and lots of little transactions and onyl a few big ones.

The machine in question will do nothing but serve databases.  It's a
dual 3.2Ghz Xeon with 100GB or 15K RPM RAID 5 and 8 GB of RAM.  I'd
like to configure it to get the most out of the server possible as far
as shared memory, sort memore, etc.  I haven't found a lot of
documentation on this.

By the way, for some reason Postgres 7.4.x wouldn't install properly -
had a problem with initdb - had to use 7.3.6

Any help is greatly appreciated.

-John

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [GENERAL] postgresql.conf

[Scott Marlowe]

On Wed, 2004-12-22 at 09:15, John Cunningham wrote:
 Hey Guys,
 
 I am setting up a new dedicated Postgres server, and will serve about
 60 databases to a web site serving 250,000 people at the rate of about
 20,000 a day.  That may all be irrellevent though for the purposes of
 this conversation.
 

If you're gonna handle a lot of connections at the same time, look at
pgpool.  Also, the tuning docs at varlena are a must:

http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html

 The main thing about the application is that we're talking about lots
 and lots of little transactions and onyl a few big ones.
 
 The machine in question will do nothing but serve databases.  It's a
 dual 3.2Ghz Xeon with 100GB or 15K RPM RAID 5 and 8 GB of RAM.  I'd
 like to configure it to get the most out of the server possible as far
 as shared memory, sort memore, etc.  I haven't found a lot of
 documentation on this.

Battery backed cache on the hardware RAID controller is a must. RAID 1+0
may be a better choice than RAID 5, depending on your usage patterns.

 By the way, for some reason Postgres 7.4.x wouldn't install properly -
 had a problem with initdb - had to use 7.3.6

Please post the error messages you got and what OS / version of that OS
you're running, and any other relevant information you can think of. 
7.4 is fairly stable, a failed install is something that generally
shouldn't happen, and when it does, it's usually not 7.4's fault
nowadays.


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [GENERAL] postgresql.conf

[Steve Wampler]

John Cunningham wrote:
...
The machine in question will do nothing but serve databases.  It's a
dual 3.2Ghz Xeon with 100GB or 15K RPM RAID 5 and 8 GB of RAM.  I'd
like to configure it to get the most out of the server possible as far
as shared memory, sort memore, etc.  I haven't found a lot of
documentation on this.
What OS?
By the way, for some reason Postgres 7.4.x wouldn't install properly -
had a problem with initdb - had to use 7.3.6
I had a similar problem under Fedora Core 3 that Tom Lane solved quickly
for me.  From my notes:
   Run '/usr/sbin/setenforce 0' before intializing database.
   Ok to turn back on with '/usr/sbin/setenforce 1' afterwards.
Has to do with the Fedora using SELinux by default now.
Dunno if that is your situation...
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [GENERAL] postgresql.conf

[Frank D. Engel, Jr.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 22, 2004, at 10:15 AM, John Cunningham wrote:
like to configure it to get the most out of the server possible as far
as shared memory, sort memore, etc.  I haven't found a lot of
documentation on this.
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
- ---
Frank D. Engel, Jr.  [EMAIL PROTECTED]
$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep John 3:16
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
$
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFByZnw7aqtWrR9cZoRAgl8AJ9PcpktGBeA/Oboh5+ZKPwS1niP9QCfZaL3
yf1Yvav5baMeQZOjGmvmk6E=
=Hnti
-END PGP SIGNATURE-

___
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match

Re: [GENERAL] postgresql.conf

[John Cunningham]

I'm running Red Hat Enterprise ES with all the most recent updates.

The error - in initdb - was that the system couldn't find
ascii_and_mic libraries.  7.3.6 ran without a hitch.

The RAID 1+0 - is that a stripped / mirrored condifuration?  How big
of a difference will that make in performance do you think - are we
talking 10 % or leaps and bounds?

The help is much appreciated - I'm reading that tuning manual now.

-John




On Wed, 22 Dec 2004 10:59:43 -0500, Frank D. Engel, Jr.
[EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 On Dec 22, 2004, at 10:15 AM, John Cunningham wrote:
 
  like to configure it to get the most out of the server possible as far
  as shared memory, sort memore, etc.  I haven't found a lot of
  documentation on this.
 
 http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
 
 - ---
 Frank D. Engel, Jr.  [EMAIL PROTECTED]
 
 $ ln -s /usr/share/kjvbible /usr/manual
 $ true | cat /usr/manual | grep John 3:16
 John 3:16 For God so loved the world, that he gave his only begotten
 Son, that whosoever believeth in him should not perish, but have
 everlasting life.
 $
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.2.4 (Darwin)
 
 iD8DBQFByZnw7aqtWrR9cZoRAgl8AJ9PcpktGBeA/Oboh5+ZKPwS1niP9QCfZaL3
 yf1Yvav5baMeQZOjGmvmk6E=
 =Hnti
 -END PGP SIGNATURE-
 
 ___
 $0 Web Hosting with up to 120MB web space, 1000 MB Transfer
 10 Personalized POP and Web E-mail Accounts, and much more.
 Signup at www.doteasy.com
 
 ---(end of broadcast)---
 TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [GENERAL] postgresql.conf

[Lonni J Friedman]

On Wed, 22 Dec 2004 10:38:01 -0600, John Cunningham [EMAIL PROTECTED] wrote:
 I'm running Red Hat Enterprise ES with all the most recent updates.
 
 The error - in initdb - was that the system couldn't find
 ascii_and_mic libraries.  7.3.6 ran without a hitch.

That's very odd, cause I'm using 7.4.6 RPMs on RHEL-3 without any
problems.  Is there anything unusual about your installation?  You
tried with the RPMs from the postgresql.org FTP server, right?

-- 
~
L. Friedman[EMAIL PROTECTED]
LlamaLand   http://netllama.linux-sxs.org

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: [GENERAL] postgresql.conf

[John Cunningham]

OK Guys - here's the config file as I've writtten it.

I'll paste in the whole thing before, but this is the important stuff:

max_connections = 256
shared_buffers = 32768   # (256 MB)
sort_mem = 1024 # min 64, size in KB
fsync = No
wal_sync_method = fsync # the default varies across platforms:
effective_cache_size = 786432   # (6 GB)
random_page_cost = 2# units are one sequential page fetch cost

I am seriously considering breaking the machine all the way down and
changing to a stripped / mirrored config if that will be the fastest
way to run it.  Need advice on that.  Here's the config file:

#


#
#   Connection Parameters
#
tcpip_socket = false
#ssl = false

max_connections = 256
superuser_reserved_connections = 2

port = 5432
#hostname_lookup = false
#show_source_port = false

#unix_socket_directory = ''
#unix_socket_group = ''
#unix_socket_permissions = 0777 # octal

#virtual_host = ''

#krb_server_keyfile = ''


#
#   Shared Memory Size
#
shared_buffers = 32768  # min max_connections*2 or 16, 8KB each
#max_fsm_relations = 1000   # min 10, fsm is free space map, ~40 bytes
#max_fsm_pages = 1  # min 1000, fsm is free space map, ~6 bytes
#max_locks_per_transaction = 64 # min 10
#wal_buffers = 8# min 4, typically 8KB each

#
#   Non-shared Memory Sizes
#
sort_mem = 1024 # min 64, size in KB
#vacuum_mem = 8192  # min 1024, size in KB

#
#   Write-ahead log (WAL)
#
#checkpoint_segments = 3# in logfile segments, min 1, 16MB each
#checkpoint_timeout = 300   # range 30-3600, in seconds
#
#commit_delay = 0   # range 0-10, in microseconds
#commit_siblings = 5# range 1-1000
#
fsync = No
wal_sync_method = fsync # the default varies across platforms:
#   # fsync, fdatasync, open_sync, or open_datasync
#wal_debug = 0  # range 0-16


#
#   Optimizer Parameters
#
#enable_seqscan = true
#enable_indexscan = true
#enable_tidscan = true
#enable_sort = true
#enable_nestloop = true
#enable_mergejoin = true
#enable_hashjoin = true

effective_cache_size = 786432   # typically 8KB each
random_page_cost = 2# units are one sequential page fetch cost
#cpu_tuple_cost = 0.01  # (same)
#cpu_index_tuple_cost = 0.001   # (same)
#cpu_operator_cost = 0.0025 # (same)

#default_statistics_target = 10 # range 1-1000

#
#   GEQO Optimizer Parameters
#
#geqo = true
#geqo_selection_bias = 2.0  # range 1.5-2.0
#geqo_threshold = 11
#geqo_pool_size = 0 # default based on tables in statement,
# range 128-1024
#geqo_effort = 1
#geqo_generations = 0
#geqo_random_seed = -1  # auto-compute seed

#
#   Message display
#
#server_min_messages = notice   # Values, in order of decreasing detail:
#   debug5, debug4, debug3, debug2, debug1,
#   info, notice, warning, error, log, fatal,
#   panic
#client_min_messages = notice   # Values, in order of decreasing detail:
#   debug5, debug4, debug3, debug2, debug1,
#   log, info, notice, warning, error
#silent_mode = false

#log_connections = false
#log_pid = false
#log_statement = false
#log_duration = false
#log_timestamp = false

#log_min_error_statement = panic # Values in order of increasing severity:
 #   debug5, debug4, debug3, debug2, debug1,
 #   info, notice, warning, error, panic(off)

#debug_print_parse = false
#debug_print_rewritten = false
#debug_print_plan = false
#debug_pretty_print = false

#explain_pretty_print = true

# requires USE_ASSERT_CHECKING
#debug_assertions = true


#
#   Syslog
#
#syslog = 0 # range 0-2
#syslog_facility = 'LOCAL0'
#syslog_ident = 'postgres'


#
#   Statistics
#
#show_parser_stats = false
#show_planner_stats = false
#show_executor_stats = false
#show_statement_stats = false

# requires BTREE_BUILD_STATS
#show_btree_build_stats = false

#
#   Access statistics collection
#
#stats_start_collector = true
#stats_reset_on_server_start = true
#stats_command_string = false
#stats_row_level = false
#stats_block_level = false


#
#   Lock Tracing
#
#trace_notify = false

# requires LOCK_DEBUG
#trace_locks = false
#trace_userlocks = false
#trace_lwlocks = false
#debug_deadlocks = false
#trace_lock_oidmin = 16384
#trace_lock_table = 0


#
#   Misc
#
#autocommit = true
#dynamic_library_path = '$libdir'
#search_path = '$user,public'
#datestyle = 'iso, us'
#timezone = unknown # actually, defaults to TZ environment setting
#australian_timezones = false
#client_encoding = sql_ascii# actually, defaults to database encoding
#authentication_timeout = 60# 1-600, in seconds

Re: [GENERAL] postgresql.conf

[Scott Marlowe]

On Wed, 2004-12-22 at 11:30, John Cunningham wrote:
 OK Guys - here's the config file as I've writtten it.
 
 I'll paste in the whole thing before, but this is the important stuff:
 
 max_connections = 256

Are you using a connection pooling scheme (jdbc based pooling, pgpool,
etc...)?  If not, you probably should, and then drop the max connections
to something much smaller, like 30 or 40 or so.  If you can.

 shared_buffers = 32768   # (256 MB)

That's really high, even for a machine with 6+ gigs of ram.  Unless
you're working data set is that big, it's too big.  IF, on average,
you're working with smaller amounts of data at a time, it might be
better to drop it down to 5000 to 1.  Few, if any benchmarks have
shown an improvement at settings over 1.  OTOH, you might be the one
person out of a thousand or so who needs larger shared_buffers.  Note
that shared buffers aren't cache, and when the last backend referencing
a particular data set in memory stops referencing it, the data it
dropped and the buffer memory released back to the pool, so to speak. 
The kernel is generally better at caching than postgresql anyway.

With 8.0's ARC cache algorithm in place, it might be time for someone to
start testing postgresql with a persistant buffer cache (i.e. make it
hold on to the old data sets intead of freeing up the space.)

 sort_mem = 1024 # min 64, size in KB

You can probably up this a bit, especially if you pool your
connections.  Try 8192 for a starting point.  Setting this too large can
be dangerous to the health of your OS, since you can starve the OS for
memory and make it start swapping processes out to come up with sort_mem

 fsync = No

Not really safe, and not the performance gain it once was, if I remember
a post from Tom recently correctly.  On the other hand, IDE disks do
this by design, so if you were using those (with their cache enabled)
you'd be in the same boat.

 wal_sync_method = fsync # the default varies across platforms:
 effective_cache_size = 786432   # (6 GB)
 random_page_cost = 2# units are one sequential page fetch cost

You can probably drop this down to 1.2 to 1.4 or so on a machine with a
fast disk subsystem and caching controller.

 I am seriously considering breaking the machine all the way down and
 changing to a stripped / mirrored config if that will be the fastest
 way to run it.  Need advice on that.  Here's the config file:

Do you have a battery backed caching raid controller?  If not, that's
one of the first steps to better performance.  After that, if you've got
lots of disks, a RAID 5 or RAID 1+0 should both be pretty fast.  If
you've got 8 or so disks, the RAID 1+0 will normally be faster,
assuming your RAID controller handles that configuration well.  Some
older / cheaper controllers can't parallelize their I/O and run the same
speed in 1+0 as they would in plain old 1.


 #max_fsm_relations = 1000   # min 10, fsm is free space map, ~40 bytes
 #max_fsm_pages = 1  # min 1000, fsm is free space map, ~6 bytes

Are you sure you're vacuuming often enough and that these settings are
high enough?  What does 'vacuum verbose' on your database say?  You
might want to use pg_autovacuum to ensure sufficient vacuuming is taking
place.

 #
 #   Locale settings
 #
 # (initialized by initdb -- may be changed)
 LC_MESSAGES = 'en_US.UTF-8'
 LC_MONETARY = 'en_US.UTF-8'
 LC_NUMERIC = 'en_US.utf-8'
 LC_TIME = 'en_US.UTF-8'

Are you doing a lot of text searching?  If so, you might be better off
initing the database with locale=C instead.

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [GENERAL] postgresql.conf

[John Cunningham]

The server is a DELL Poweredge 2650 with it's built in RAID - 4 disks
currently in a RAID 5 config.  I will check on the battery backup.

I'm putting this server together and rebuilding our overall db
structure all at the same time, so I have a good amount of flexiblity.
 I realized I was not taking as much advantage of the machine as
possible before - hence the call out to the list.

I'll look in to the persistent connections - last time we built this
it was several versions ago and the overall attitude was that it
didn't work terrible well.  Is this a PG setting or something in PHP?

The shared buffers was a big concern - I've read that there's a limit
that helps, but as the machine will only do DB transactions, I don't
know what else to do with the RAM.  It's intended for PG's use.

Obviously I'd rather have fsync on - I was really looking for some
opinions on this.  Better safe than sorry - but I am trying to sqeeze
every bit of juice possible out of this machine.

The machine has 4 drives - should I do a RAID 1+0 or a 5?

Most of the searching is char fields then linking ids from one table to another.

BTW - this is one of the best discussions I've been on - glad everyone
can be so helpful.

Thanks!
-John



On Wed, 22 Dec 2004 12:08:10 -0600, Scott Marlowe
[EMAIL PROTECTED] wrote:
 On Wed, 2004-12-22 at 11:30, John Cunningham wrote:
  OK Guys - here's the config file as I've writtten it.
 
  I'll paste in the whole thing before, but this is the important stuff:
 
  max_connections = 256
 
 Are you using a connection pooling scheme (jdbc based pooling, pgpool,
 etc...)?  If not, you probably should, and then drop the max connections
 to something much smaller, like 30 or 40 or so.  If you can.
 
  shared_buffers = 32768   # (256 MB)
 
 That's really high, even for a machine with 6+ gigs of ram.  Unless
 you're working data set is that big, it's too big.  IF, on average,
 you're working with smaller amounts of data at a time, it might be
 better to drop it down to 5000 to 1.  Few, if any benchmarks have
 shown an improvement at settings over 1.  OTOH, you might be the one
 person out of a thousand or so who needs larger shared_buffers.  Note
 that shared buffers aren't cache, and when the last backend referencing
 a particular data set in memory stops referencing it, the data it
 dropped and the buffer memory released back to the pool, so to speak.
 The kernel is generally better at caching than postgresql anyway.
 
 With 8.0's ARC cache algorithm in place, it might be time for someone to
 start testing postgresql with a persistant buffer cache (i.e. make it
 hold on to the old data sets intead of freeing up the space.)
 
  sort_mem = 1024 # min 64, size in KB
 
 You can probably up this a bit, especially if you pool your
 connections.  Try 8192 for a starting point.  Setting this too large can
 be dangerous to the health of your OS, since you can starve the OS for
 memory and make it start swapping processes out to come up with sort_mem
 
  fsync = No
 
 Not really safe, and not the performance gain it once was, if I remember
 a post from Tom recently correctly.  On the other hand, IDE disks do
 this by design, so if you were using those (with their cache enabled)
 you'd be in the same boat.
 
  wal_sync_method = fsync # the default varies across platforms:
  effective_cache_size = 786432   # (6 GB)
  random_page_cost = 2# units are one sequential page fetch cost
 
 You can probably drop this down to 1.2 to 1.4 or so on a machine with a
 fast disk subsystem and caching controller.
 
  I am seriously considering breaking the machine all the way down and
  changing to a stripped / mirrored config if that will be the fastest
  way to run it.  Need advice on that.  Here's the config file:
 
 Do you have a battery backed caching raid controller?  If not, that's
 one of the first steps to better performance.  After that, if you've got
 lots of disks, a RAID 5 or RAID 1+0 should both be pretty fast.  If
 you've got 8 or so disks, the RAID 1+0 will normally be faster,
 assuming your RAID controller handles that configuration well.  Some
 older / cheaper controllers can't parallelize their I/O and run the same
 speed in 1+0 as they would in plain old 1.
 
 
  #max_fsm_relations = 1000   # min 10, fsm is free space map, ~40 bytes
  #max_fsm_pages = 1  # min 1000, fsm is free space map, ~6 bytes
 
 Are you sure you're vacuuming often enough and that these settings are
 high enough?  What does 'vacuum verbose' on your database say?  You
 might want to use pg_autovacuum to ensure sufficient vacuuming is taking
 place.
 
  #
  #   Locale settings
  #
  # (initialized by initdb -- may be changed)
  LC_MESSAGES = 'en_US.UTF-8'
  LC_MONETARY = 'en_US.UTF-8'
  LC_NUMERIC = 'en_US.utf-8'
  LC_TIME = 'en_US.UTF-8'
 
 Are you doing a lot of text searching?  If so, you might be better off
 initing the database with locale=C instead.


---(end of 

Re: [GENERAL] postgresql.conf

[Frank D. Engel, Jr.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 22, 2004, at 2:36 PM, John Cunningham wrote:
The shared buffers was a big concern - I've read that there's a limit
that helps, but as the machine will only do DB transactions, I don't
know what else to do with the RAM.  It's intended for PG's use.
Try it both ways: with 32000 and with 1.  If 32000 gives you a 
perceptible performance increase when numerous users are connected, use 
it.  Otherwise, stick with the 1.  I suspect that depending on the 
queries themselves and the number of users involved, 1 may actually 
be faster than 32000, since you are freeing memory for use by other 
activities within the server.

Obviously I'd rather have fsync on - I was really looking for some
opinions on this.  Better safe than sorry - but I am trying to sqeeze
every bit of juice possible out of this machine.
Keep it on.  The tiny amount of extra performance will mean nothing if 
you lose important data over it.

The machine has 4 drives - should I do a RAID 1+0 or a 5?
1+0, definitely.
- ---
Frank D. Engel, Jr.  [EMAIL PROTECTED]
$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep John 3:16
John 3:16 For God so loved the world, that he gave his only begotten 
Son, that whosoever believeth in him should not perish, but have 
everlasting life.
$
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBydpA7aqtWrR9cZoRAsgpAKCG1X+9K/5dNv9boIEdnUdEljYINACggnoD
V0rpgscodJUBWcKaIG9uEGg=
=13j7
-END PGP SIGNATURE-

___
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly

Re: [GENERAL] postgresql.conf

[Greg Stark]

John Cunningham [EMAIL PROTECTED] writes:

 The shared buffers was a big concern - I've read that there's a limit
 that helps, but as the machine will only do DB transactions, I don't
 know what else to do with the RAM.  It's intended for PG's use.

The kernel will use it for disk caching which is exactly what you want it used
for anyways.

-- 
greg


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [GENERAL] postgresql.conf

[Mihai Gheorghiu]

Thank you very much.
Actually, it was the optimization parameters that I was interested in. My db
works rather slow even in single user mode and I wondered if I had missed
some setup. BTW, is there a way to see what parameters are in effect?

-Original Message-
From: Lamar Owen [EMAIL PROTECTED]
To: Mihai Gheorghiu [EMAIL PROTECTED]; [EMAIL PROTECTED]
[EMAIL PROTECTED]
Date: Tuesday, September 25, 2001 8:30 PM
Subject: Re: [GENERAL] postgresql.conf


On Tuesday 25 September 2001 11:34 am, Mihai Gheorghiu wrote:
 I installed PG from RPMs. postgresql.conf comes with all options
commented
 out.
 What are the defaults? PG works anyway (Well... I know... -i etc.)
 Thank you all.

All options commented out is the installation default of a from-source
install as well as the RPM install.  The default values for the various
paramters are commented inside the file, IIRC.

Use tcpip_socket=true instead of -i

I made the conscious decision to ship the default postgresql.conf -- what
optimizations should I make?  I can't make generalized optimizations -- so
I
ship the default file.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[GENERAL] postgresql.conf

[Mihai Gheorghiu]

I installed PG from RPMs. postgresql.conf comes with all options commented
out.
What are the defaults? PG works anyway (Well... I know... -i etc.)
Thank you all.


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [GENERAL] postgresql.conf

[Lamar Owen]

On Tuesday 25 September 2001 11:34 am, Mihai Gheorghiu wrote:
 I installed PG from RPMs. postgresql.conf comes with all options commented
 out.
 What are the defaults? PG works anyway (Well... I know... -i etc.)
 Thank you all.

All options commented out is the installation default of a from-source 
install as well as the RPM install.  The default values for the various 
paramters are commented inside the file, IIRC.

Use tcpip_socket=true instead of -i

I made the conscious decision to ship the default postgresql.conf -- what 
optimizations should I make?  I can't make generalized optimizations -- so I 
ship the default file.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [GENERAL] postgresql.conf ignored

[Peter Eisentraut]

hafiz writes:

 I use Postgresql 7.0.3-2 in red-hat 6.2

 I change several postmaster options through postgresql.conf (in
 /usr/local/pgsql/data) . But it seems
 that the postmaster still run using default values and ignored
 postgresql.conf. I've check the file permission and it should be ok.

This file is new in 7.1.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: [GENERAL] postgresql.conf ignored

[Lamar Owen]

hafiz wrote:
 I use Postgresql 7.0.3-2 in red-hat 6.2
 
 I change several postmaster options through postgresql.conf (in
 /usr/local/pgsql/data) . But it seems
 that the postmaster still run using default values and ignored
 postgresql.conf. I've check the file permission and it should be ok.

postgresql.conf is new for 7.1.  The proper 7.0.3 file is pg_options,
and postmaster.options.sample (IIRC).  Might be just
postmaster.opts.sample.  I don't have a 7.0.3 machine accessible right
now to tell -- my production server (for various reasons) is back on a
previous version, and my development server has 7.1beta3 installed. 
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11