Some roles (users or groups) can be restricted in setting the
configuration parameters. The administrator can define particular
restricions in the guc_limits.json
file and put it
into the data directory.
The file is a JSON array where each element represents a single limit. Multiple limits can be assigned to a single variable. The following limit attributes are required regardless the parameter data type:
var_name
Name of the variable (parameter) whose values should be limited.
roles
List of roles (users, groups) who cannot change the variable value beyond the limit.
The other attributes are only applicable to parameters of specific data types.
value
The allowed value of the parameter.
value
The allowed value of the parameter.
allow_empty
Can the parameter be set to empty string? The default value
is true
.
min
Minimum value of the parameter.
max
Maximum value of the parameter.
min
Minimum value of the parameter.
include_min
Is the minimum value allowed itself? The default value
is false
.
max
Maximum value of the parameter.
include_max
Is the maximum value allowed itself? The default value
is false
.
values
The list of values the parameter can be assigned.
The following sample file shows how limits can be imposed on configuration parameters of different data types.
[ { "var_name" : "enable_seqscan", "value" : true, "roles" : ["app1"] }, { "var_name" : "work_mem", "min" : 1024, "max" : 2048, "roles" : ["monitor"] }, { "var_name" : "work_mem", "min" : 1024, "max" : "16MB", "roles" : ["admin"] }, { "var_name" : "max_parallel_workers", "max" : 10, "roles" : ["app1", "app2"] }, { "var_name" : "default_tablespace", "value" : "tbsp_app1", "roles" : ["app1"] }, { "var_name" : "client_min_messages", "values" : ["log", "info", "notice", "warning", "error"], "roles" : ["app1", "app2"] } ]
You can enforce rereading of the guc_limits.json
file in the same way as you would do
for postgresql.conf
: by running pg_ctl
reload
from the command line or by calling the SQL
function pg_reload_conf()
.