Tom Lane wrote:
>
> I'd turn that around: I think you are arguing for a way to change GUC
> settings on-the-fly for a single existing session, without cooperation
> from the client.
Ok, implemented that way would solve it (partially)
Something like pg_set_guc(pid int4, varname text, value text) would be
fine to set GUC on-the-fly. Could probably be signaled to the target
backend with SIGHUP, but how should the individual parameter be
transmitted, and eventually be retrieved? What about multiple parameters
to be set atomically?
A different aproach: A system table pg_guc, that holds current GUC
settings for each backend.
- on SIGHUP, the backend reload postgresql.conf as usual and writes guc
into pg_guc, unless a "config file override" flag is set.
- if pg_guc.config_override is set, guc are read from the table instead,
and the flag is reset.
- truncate pg_guc on postmaster start/restart
Regards,
Andreas
PS the non-solved part for me is still that log_statement logging would
still go to the standard log, in a less machine-readable way, mixed with
other backend's data and possibly truncated. But that's a different story.
---------------------------(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
