Re: remote query debugging was: Plugins redux
От | Andreas Pflug |
---|---|
Тема | Re: remote query debugging was: Plugins redux |
Дата | |
Msg-id | 44DA49B1.5030406@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: remote query debugging was: Plugins redux (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: