Sample configuration files
We have sample configuration files for postgresql.conf and
recovery.conf, but we do not have them for contrib modules. This patch
attempts to add them.
Although the patch puts the sample configuration files in the tree, it
doesn't try to install them. That's partly because I think it would
need an extension version bump and that doesn't seem worth it.
Also, while writing this patch, it crossed my mind that the plpgsql
variables should probably be in the main postgresql.conf file because we
install it by default. I will happily write that patch if desired,
independently of this patch.
Current as of 26fa446, added to next commitfest.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Attachments:
sample_confs_v01.patchinvalid/octet-stream; name=sample_confs_v01.patchDownload
diff --git a/contrib/auth_delay/auth_delay.conf.sample b/contrib/auth_delay/auth_delay.conf.sample
new file mode 100644
index 0000000..931a7e1
--- /dev/null
+++ b/contrib/auth_delay/auth_delay.conf.sample
@@ -0,0 +1,6 @@
+# -----------------------------
+# auth_delay configuration file
+# -----------------------------
+
+# Delay before reporting authentication failure
+#auth_delay.milliseconds = 0
diff --git a/contrib/auto_explain/auto_explain.conf.sample b/contrib/auto_explain/auto_explain.conf.sample
new file mode 100644
index 0000000..d653690
--- /dev/null
+++ b/contrib/auto_explain/auto_explain.conf.sample
@@ -0,0 +1,31 @@
+# -------------------------------
+# auto_explain configuration file
+# -------------------------------
+
+# Set the minimum execution time above which plans will be logged
+#auto_explain.log_min_duration = -1 # in milliseconds, -1 disables
+
+# Use EXPLAIN ANALYZE for plan logging
+#auto_explain.log_analyze = off
+
+# Use EXPLAIN VERBOSE for plan logging
+#auto_explain.log_verbose = off
+
+# Log buffers usage
+#auto_explain.log_buffers = off
+
+# Include statistics in plans
+#auto_explain.log_triggers = off # requires log_analyze to also be on
+
+# EXPLAIN format to be used for plan logging
+#auto_explain.log_format = text # text, xml, json, or yaml
+
+# Log nested statements
+#auto_explain.log_nested_statements = off
+
+# Collect timing data, not just row counts
+#auto_explain.log_timing = on
+
+# Fraction of queries to process
+#auto_explain.sample_rate = 1.0 # range 0.0 - 1.0
+
diff --git a/contrib/pg_stat_statements/pg_stat_statements.conf.sample b/contrib/pg_stat_statements/pg_stat_statements.conf.sample
new file mode 100644
index 0000000..4e8dc66
--- /dev/null
+++ b/contrib/pg_stat_statements/pg_stat_statements.conf.sample
@@ -0,0 +1,15 @@
+# -------------------------------------
+# pg_stat_statements configuration file
+# -------------------------------------
+
+# Set the maximum number of statements to track
+#pg_stat_statements.max = 5000 # minimum 100
+
+# Select which statements are tracked
+#pg_stat_statements.track = top # none, top, or all
+
+# Select whether utility commands are tracked
+#pg_stat_statements.track_utility = on
+
+# Save statistics across server shutdowns
+#pg_stat_statements.save = on
diff --git a/contrib/pg_trgm/pg_trgm.conf.sample b/contrib/pg_trgm/pg_trgm.conf.sample
new file mode 100644
index 0000000..3118bbe
--- /dev/null
+++ b/contrib/pg_trgm/pg_trgm.conf.sample
@@ -0,0 +1,9 @@
+# --------------------------
+# pg_trgm configuration file
+# --------------------------
+
+# Set the threshold used by the %% operator.
+#pg_trgm.similarity_threshold = 0.3 # range 0.0 - 1.0
+
+# Set the threshold used by the <%% operator.
+#pg_trgm.word_similarity_threshold = 0.6 # range 0.0 - 1.0
diff --git a/contrib/sepgsql/sepgsql.conf.sample b/contrib/sepgsql/sepgsql.conf.sample
new file mode 100644
index 0000000..f7f0ec0
--- /dev/null
+++ b/contrib/sepgsql/sepgsql.conf.sample
@@ -0,0 +1,9 @@
+# --------------------------
+# sepgsql configuration file
+# --------------------------
+
+# Turn on/off permissive mode in SE-PostgreSQL
+#sepgsql.permissive = off
+
+# Turn on/off debug audit messages
+#sepgsql.debug_audit = off
diff --git a/src/pl/plperl/plperl.conf.sample b/src/pl/plperl/plperl.conf.sample
new file mode 100644
index 0000000..7bba7b9
--- /dev/null
+++ b/src/pl/plperl/plperl.conf.sample
@@ -0,0 +1,15 @@
+# -------------------------
+# plperl configuration file
+# -------------------------
+
+# Compile trusted and untrusted Perl code in strict mode
+#plperl.use_strict = off
+
+# Perl code to execute when a Perl interpreter is initialized
+#plperl.on_init = ''
+
+# Perl code to execute once when plperl is first used
+#plperl.on_plperl_init = ''
+
+# Perl code to execute once when plperlu is first used
+#plperl.on_plperl_init = ''
diff --git a/src/pl/plpgsql/src/plpgsql.conf.sample b/src/pl/plpgsql/src/plpgsql.conf.sample
new file mode 100644
index 0000000..39eb6fb
--- /dev/null
+++ b/src/pl/plpgsql/src/plpgsql.conf.sample
@@ -0,0 +1,19 @@
+# --------------------------
+# plpgsql configuration file
+# --------------------------
+
+# Set handling of conflicts between PL/pgSQL variable names and table column
+# names
+#plpgsql.variable_conflict = error # error, use_variable, or use_column
+
+# Print information about parameters in the DETAIL part of the error messages
+# generated on INTO ... STRICT failures
+#plpgsql.print_strict_params = off
+
+# Perform checks given in ASSERT statements
+#plpgsql.check_asserts = on
+
+# List of programming constructs that should produce a warning or an error
+# Currenty only "shadowed_variables" is supported, as well as "all" or "none"
+#plpgsql.extra_warnings = 'none'
+#plpgsql.extra_errors = 'none'
On Mon, Aug 29, 2016 at 7:04 AM, Vik Fearing <vik@2ndquadrant.fr> wrote:
We have sample configuration files for postgresql.conf and
recovery.conf, but we do not have them for contrib modules. This patch
attempts to add them.Although the patch puts the sample configuration files in the tree, it
doesn't try to install them. That's partly because I think it would
need an extension version bump and that doesn't seem worth it.
What is the use case and how these files suppose to work? Do you
expect these to be loaded as we do for postgresql.conf?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 29, 2016 at 7:04 AM, Vik Fearing <vik@2ndquadrant.fr> wrote:
We have sample configuration files for postgresql.conf and
recovery.conf, but we do not have them for contrib modules. This patch
attempts to add them.Although the patch puts the sample configuration files in the tree, it
doesn't try to install them. That's partly because I think it would
need an extension version bump and that doesn't seem worth it.
I don't think that would need an extension version bump; we only need
that if we're changing which SQL objects get created. So my opinion
of this effort is:
1. If we're going to add these files, there's no reason not to install
them; in fact, not installing them makes the whole thing rather
pointless, as most people will only see the stuff that gets installed,
not uninstalled files in the source tree.
2. But I'm not sure that this will actually be useful to people. It
seems like it might just be one more thing for patch authors to
maintain. I think that if somebody wants to set a parameter defined
for a contrib module, it's easy enough to just add an entry into
postgresql.conf, or use ALTER SYSTEM .. SET. Going and finding the
sample file (which only sets the value to the default) and then
putting that into your postgresql.conf seems like an extra step.
Of course, others may feel differently and that is fine...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/02/2016 08:58 AM, Robert Haas wrote:
On Mon, Aug 29, 2016 at 7:04 AM, Vik Fearing <vik@2ndquadrant.fr> wrote:
We have sample configuration files for postgresql.conf and
recovery.conf, but we do not have them for contrib modules. This patch
attempts to add them.Although the patch puts the sample configuration files in the tree, it
doesn't try to install them. That's partly because I think it would
need an extension version bump and that doesn't seem worth it.I don't think that would need an extension version bump; we only need
that if we're changing which SQL objects get created. So my opinion
of this effort is:1. If we're going to add these files, there's no reason not to install
them; in fact, not installing them makes the whole thing rather
pointless, as most people will only see the stuff that gets installed,
not uninstalled files in the source tree.
Fair enough. The alternative is for packagers to install them, like
they do for recovery.conf.sample. I'll update the patch as soon as we
get consensus that this is wanted.
2. But I'm not sure that this will actually be useful to people. It
seems like it might just be one more thing for patch authors to
maintain. I think that if somebody wants to set a parameter defined
for a contrib module, it's easy enough to just add an entry into
postgresql.conf, or use ALTER SYSTEM .. SET. Going and finding the
sample file (which only sets the value to the default) and then
putting that into your postgresql.conf seems like an extra step.
I was imagining just using the "include" directive. I have heard the
desire for annotated sample conf files for the contrib modules twice now
from different people which is why I wrote the patch. If we decide that
the extra documentation is too much of a burden, I can understand that,
also.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
El 02/09/16 a las 04:19, Vik Fearing escribió:
2. But I'm not sure that this will actually be useful to people. It
seems like it might just be one more thing for patch authors to
maintain. I think that if somebody wants to set a parameter defined
for a contrib module, it's easy enough to just add an entry into
postgresql.conf, or use ALTER SYSTEM .. SET. Going and finding the
sample file (which only sets the value to the default) and then
putting that into your postgresql.conf seems like an extra step.I was imagining just using the "include" directive. I have heard the
desire for annotated sample conf files for the contrib modules twice now
from different people which is why I wrote the patch. If we decide that
the extra documentation is too much of a burden, I can understand that,
also.
I think having a sample configuration file which we can include and make
the specific configuration changes for that contrib has it's logic, and
I believe it's a good idea to include.
We suggest having a bdr.conf file separated with all the BDR
configuration parameters, so this makes total sense.
I will have a better check at the patch and get back (didn't find
anything wrong at the first look at it).
Regards,
--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/29/2016 03:34 AM, Vik Fearing wrote:
We have sample configuration files for postgresql.conf and
recovery.conf, but we do not have them for contrib modules. This patch
attempts to add them.Although the patch puts the sample configuration files in the tree, it
doesn't try to install them. That's partly because I think it would
need an extension version bump and that doesn't seem worth it.Also, while writing this patch, it crossed my mind that the plpgsql
variables should probably be in the main postgresql.conf file because we
install it by default. I will happily write that patch if desired,
independently of this patch.Current as of 26fa446, added to next commitfest.
I noticed that this patch has been marked Waiting on Author with no
comment. Peter, what more should I be doing right now while waiting for
Martín's review?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Vik Fearing <vik@2ndquadrant.fr> writes:
I noticed that this patch has been marked Waiting on Author with no
comment. Peter, what more should I be doing right now while waiting for
Martín's review?
FWIW, I agree with the upthread misgivings about whether this is actually
a useful effort. Even if we installed the sample config files somewhere
(something there is not consensus for AFAICT), they would not actually
*do* anything useful as standalone files. I suppose you are imagining
that people would either manually concatenate them onto postgresql.conf
or insert an include directive for them into postgresql.conf, but neither
of those things sound pleasant or maintainable.
Moreover, it's not clear why anyone would do that at all in the age of
ALTER SYSTEM SET.
I suggest that it'd be more fruitful to view this as a documentation
effort; that is, in each contrib module's SGML documentation file provide
a standardized section listing all its parameters and their default
settings. That would be something that could be copied-and-pasted from
into either an editor window on postgresql.conf for the old guard, or
an ALTER SYSTEM SET command for the new.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 8, 2016 at 8:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Vik Fearing <vik@2ndquadrant.fr> writes:
I noticed that this patch has been marked Waiting on Author with no
comment. Peter, what more should I be doing right now while waiting for
Martín's review?FWIW, I agree with the upthread misgivings about whether this is actually
a useful effort. Even if we installed the sample config files somewhere
(something there is not consensus for AFAICT), they would not actually
*do* anything useful as standalone files. I suppose you are imagining
that people would either manually concatenate them onto postgresql.conf
or insert an include directive for them into postgresql.conf, but neither
of those things sound pleasant or maintainable.Moreover, it's not clear why anyone would do that at all in the age of
ALTER SYSTEM SET.I suggest that it'd be more fruitful to view this as a documentation
effort; that is, in each contrib module's SGML documentation file provide
a standardized section listing all its parameters and their default
settings. That would be something that could be copied-and-pasted from
into either an editor window on postgresql.conf for the old guard, or
an ALTER SYSTEM SET command for the new.
So, tallying up the votes, one person has spoken in favor of this
(Martín Marqués) and two against it (Tom Lane and Robert Haas). One
presumes the author is also in favor, so that's a 2-2 tie. That's not
exactly a consensus against this effort, but it's not a ringing
endorsement, either. It's hard for me to imagine anything getting
committed here unless some more people think it's a good idea.
So, anyone else have an opinion, pro or con?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 29, 2016 at 2:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
So, anyone else have an opinion, pro or con?
Going through this thread, I'd vote -1. This is a documentation effort
mainly, and installing those files has zero effect if they are not
loaded via include_if_exists or include in postgresql.conf.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 09/29/2016 05:55 AM, Michael Paquier wrote:
On Thu, Sep 29, 2016 at 2:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
So, anyone else have an opinion, pro or con?
Going through this thread, I'd vote -1. This is a documentation effort
mainly, and installing those files has zero effect if they are not
loaded via include_if_exists or include in postgresql.conf.
Just the other day, I needed this patch yet again but had to go look up
the documentation instead.
I wonder if it would be a good idea to have a postgresql.conf.d
directory that postgresql.conf would include_dir by default. These
could then live in there and all I would have had to do is uncomment the
values I wanted.
This patch doesn't do that, of course, but I could easily write a patch
that does. Would that go over better with the -1ers?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Sep 29, 2016 at 2:50 PM, Vik Fearing <vik@2ndquadrant.fr> wrote:
I wonder if it would be a good idea to have a postgresql.conf.d
directory that postgresql.conf would include_dir by default. These
could then live in there and all I would have had to do is uncomment the
values I wanted.
This has more potential. And allow extensions to install config files
in share/config/, not necessarily as .sample files, but you imply it I
guess.
This patch doesn't do that, of course, but I could easily write a patch
that does. Would that go over better with the -1ers?
For now I have changed the patch as returned with feedback, the CF is
wrapping up.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers