pgsql: Make it possible to change Kerberos/GSSAPI parameters without

Started by Magnus Haganderover 17 years ago3 messagescomitters
Jump to latest
#1Magnus Hagander
magnus@hagander.net

Log Message:
-----------
Make it possible to change Kerberos/GSSAPI parameters without restarting
the postmaster. They are only used in backend processes, so it's just
a matter of re-labeling the GUCs.

Modified Files:
--------------
pgsql/doc/src/sgml:
config.sgml (r1.200 -> r1.201)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml?r1=1.200&r2=1.201)
pgsql/src/backend/utils/misc:
guc.c (r1.486 -> r1.487)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.486&r2=1.487)

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Magnus Hagander (#1)
Re: pgsql: Make it possible to change Kerberos/GSSAPI parameters without

mha@postgresql.org (Magnus Hagander) writes:

Log Message:
-----------
Make it possible to change Kerberos/GSSAPI parameters without restarting
the postmaster. They are only used in backend processes, so it's just
a matter of re-labeling the GUCs.

Please use the appropriate phraseology for SIGHUP parameters, namely

This parameter can only be set in the <filename>postgresql.conf</>
file or on the server command line.

regards, tom lane

#3Magnus Hagander
magnus@hagander.net
In reply to: Tom Lane (#2)
Re: pgsql: Make it possible to change Kerberos/GSSAPI parameters without

Tom Lane wrote:

mha@postgresql.org (Magnus Hagander) writes:

Log Message:
-----------
Make it possible to change Kerberos/GSSAPI parameters without restarting
the postmaster. They are only used in backend processes, so it's just
a matter of re-labeling the GUCs.

Please use the appropriate phraseology for SIGHUP parameters, namely

This parameter can only be set in the <filename>postgresql.conf</>
file or on the server command line.

Done.

There may be a few more around that area that actually needs that done..

Being someone who really doesn't know the docbook stuff - is there any
way to "template" these things? So we could just use a custom tag that
would expand into the full set of SGML tags to document a single config
option?

//Magnus