A small update for postgresql.conf.sample
Attached is a small patch that adds a few comments for the settings that
require restart. Applicable for 9.0+.
Regards,
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Attachments:
postgresql.conf-avmaxw.patchtext/x-patch; charset=UTF-8; name=postgresql.conf-avmaxw.patchDownload
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample
index d31f1a1..b6a8f91 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -151,6 +151,7 @@
# - Settings -
#wal_level = minimal # minimal, archive, or hot_standby
+ # (change requires restart)
#fsync = on # turns forced synchronization on or off
#synchronous_commit = on # immediate fsync at commit
#wal_sync_method = fsync # the default is the first option
@@ -186,6 +187,7 @@
# - Streaming Replication -
#max_wal_senders = 0 # max number of walsender processes
+ # (change requires restart)
#wal_sender_delay = 200ms # walsender cycle time, 1-10000 milliseconds
#wal_keep_segments = 0 # in logfile segments, 16MB each; 0 disables
#vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed
@@ -193,6 +195,7 @@
# - Standby Servers -
#hot_standby = off # "on" allows queries during recovery
+ # (change requires restart)
#max_standby_archive_delay = 30s # max delay before canceling queries
# when reading WAL from archive;
# -1 allows indefinite delay
@@ -392,7 +395,7 @@
#track_activities = on
#track_counts = on
#track_functions = none # none, pl, all
-#track_activity_query_size = 1024
+#track_activity_query_size = 1024 # (change requires restart)
#update_process_title = on
#stats_temp_directory = 'pg_stat_tmp'
@@ -416,6 +419,7 @@
# actions running at least this number
# of milliseconds.
#autovacuum_max_workers = 3 # max number of autovacuum subprocesses
+ # (change requires restart)
#autovacuum_naptime = 1min # time between autovacuum runs
#autovacuum_vacuum_threshold = 50 # min number of row updates before
# vacuum
2010/9/27 Devrim GÜNDÜZ <devrim@gunduz.org>:
Attached is a small patch that adds a few comments for the settings that
require restart. Applicable for 9.0+.
I'm not sure this is worth back-patching, but I've committed it to the
master branch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Le 27/09/2010 15:18, Robert Haas a �crit :
2010/9/27 Devrim G�ND�Z <devrim@gunduz.org>:
Attached is a small patch that adds a few comments for the settings that
require restart. Applicable for 9.0+.I'm not sure this is worth back-patching, but I've committed it to the
master branch.
+1 for backpatching.
Otherwise, the fact that "requires restart" is not here doesn't mean
anything (ie, doesn't mean if restart is required or not).
Actually, I don't see any reason why not to backpatch it.
--
Guillaume
http://www.postgresql.fr
http://dalibo.com
2010/9/27 Guillaume Lelarge <guillaume@lelarge.info>:
Le 27/09/2010 15:18, Robert Haas a écrit :
2010/9/27 Devrim GÜNDÜZ <devrim@gunduz.org>:
Attached is a small patch that adds a few comments for the settings that
require restart. Applicable for 9.0+.I'm not sure this is worth back-patching, but I've committed it to the
master branch.+1 for backpatching.
Otherwise, the fact that "requires restart" is not here doesn't mean
anything (ie, doesn't mean if restart is required or not).Actually, I don't see any reason why not to backpatch it.
I was wondering if it would cause package management headaches for
people who had already modified their postgresql.conf.
No?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On Mon, 2010-09-27 at 09:40 -0400, Robert Haas wrote:
Actually, I don't see any reason why not to backpatch it.
I was wondering if it would cause package management headaches for
people who had already modified their postgresql.conf.
We don't overwrite .conf files during upgrades.
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
2010/9/27 Devrim GÜNDÜZ <devrim@gunduz.org>:
On Mon, 2010-09-27 at 09:40 -0400, Robert Haas wrote:
Actually, I don't see any reason why not to backpatch it.
I was wondering if it would cause package management headaches for
people who had already modified their postgresql.conf.We don't overwrite .conf files during upgrades.
All right, have it your way. Done. :-)
(Dang this is a lot easier than the old way.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Excerpts from Robert Haas's message of lun sep 27 09:45:57 -0400 2010:
(Dang this is a lot easier than the old way.)
Did you use git cherry-pick?
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
2010/9/27 Alvaro Herrera <alvherre@commandprompt.com>:
Excerpts from Robert Haas's message of lun sep 27 09:45:57 -0400 2010:
(Dang this is a lot easier than the old way.)
Did you use git cherry-pick?
Yes!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Robert Haas wrote:
2010/9/27 Devrim G?ND?Z <devrim@gunduz.org>:
On Mon, 2010-09-27 at 09:40 -0400, Robert Haas wrote:
Actually, I don't see any reason why not to backpatch it.
I was wondering if it would cause package management headaches for
people who had already modified their postgresql.conf.We don't overwrite .conf files during upgrades.
All right, have it your way. Done. :-)
(Dang this is a lot easier than the old way.)
Uh, I have always been reluctant to backpatch changes to
postgresql.conf.sample because those changes are going to be installed
in share/postgresql.conf.sample during a minor upgrade. After that, if
someone diffs their data/postgresql.conf with
share/postgresql.conf.sample, they will see change that they did not
make to postgresql.conf.
Not sure you want to revert this changes, but I wanted to be sure people
understood this behavior.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
2010/10/14 Bruce Momjian <bruce@momjian.us>:
Robert Haas wrote:
2010/9/27 Devrim G?ND?Z <devrim@gunduz.org>:
On Mon, 2010-09-27 at 09:40 -0400, Robert Haas wrote:
Actually, I don't see any reason why not to backpatch it.
I was wondering if it would cause package management headaches for
people who had already modified their postgresql.conf.We don't overwrite .conf files during upgrades.
All right, have it your way. Done. :-)
(Dang this is a lot easier than the old way.)
Uh, I have always been reluctant to backpatch changes to
postgresql.conf.sample because those changes are going to be installed
in share/postgresql.conf.sample during a minor upgrade. After that, if
someone diffs their data/postgresql.conf with
share/postgresql.conf.sample, they will see change that they did not
make to postgresql.conf.Not sure you want to revert this changes, but I wanted to be sure people
understood this behavior.
Yeah, I think the horse has left the barn on these changes, since they
are in 9.0.1 at this point, but it's certainly something to keep in
mind.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas wrote:
2010/10/14 Bruce Momjian <bruce@momjian.us>:
Robert Haas wrote:
2010/9/27 Devrim G?ND?Z <devrim@gunduz.org>:
On Mon, 2010-09-27 at 09:40 -0400, Robert Haas wrote:
Actually, I don't see any reason why not to backpatch it.
I was wondering if it would cause package management headaches for
people who had already modified their postgresql.conf.We don't overwrite .conf files during upgrades.
All right, have it your way. ?Done. ?:-)
(Dang this is a lot easier than the old way.)
Uh, I have always been reluctant to backpatch changes to
postgresql.conf.sample because those changes are going to be installed
in share/postgresql.conf.sample during a minor upgrade. ?After that, if
someone diffs their data/postgresql.conf with
share/postgresql.conf.sample, they will see change that they did not
make to postgresql.conf.Not sure you want to revert this changes, but I wanted to be sure people
understood this behavior.Yeah, I think the horse has left the barn on these changes, since they
are in 9.0.1 at this point, but it's certainly something to keep in
mind.
Yes, I suspected that, but it is an effect I wanted to point out for the
future.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +