Thread: Enable logging requires restart
At the moment, to enable logging, a service restart is required. Is there any way to remove this requirement or is there a fundamental reason why it must always be like that? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown <thom@linux.com> wrote: > At the moment, to enable logging, a service restart is required. Is > there any way to remove this requirement or is there a fundamental > reason why it must always be like that? Are you speaking of the logging_collector GUC? I think the difficulty is - if you wanted to turn this on without a restart, how would you get the collector's stdin to be each backend's stdout/stderr? I don't see any way to do it, actually. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On 24 September 2010 13:17, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown <thom@linux.com> wrote: >> At the moment, to enable logging, a service restart is required. Is >> there any way to remove this requirement or is there a fundamental >> reason why it must always be like that? > > Are you speaking of the logging_collector GUC? I think the difficulty > is - if you wanted to turn this on without a restart, how would you > get the collector's stdin to be each backend's stdout/stderr? I don't > see any way to do it, actually. This is probably blasphemy, but "off" would log to a symbolic link pointing to /dev/null, which is repointed to a log_file if reloaded with "on"? -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On 24 September 2010 13:22, Thom Brown <thom@linux.com> wrote: > On 24 September 2010 13:17, Robert Haas <robertmhaas@gmail.com> wrote: >> On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown <thom@linux.com> wrote: >>> At the moment, to enable logging, a service restart is required. Is >>> there any way to remove this requirement or is there a fundamental >>> reason why it must always be like that? >> >> Are you speaking of the logging_collector GUC? I think the difficulty >> is - if you wanted to turn this on without a restart, how would you >> get the collector's stdin to be each backend's stdout/stderr? I don't >> see any way to do it, actually. > > This is probably blasphemy, but "off" would log to a symbolic link > pointing to /dev/null, which is repointed to a log_file if reloaded > with "on"? No, this is horrible. I take it back. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
On Fri, Sep 24, 2010 at 8:31 AM, Thom Brown <thom@linux.com> wrote: > On 24 September 2010 13:22, Thom Brown <thom@linux.com> wrote: >> On 24 September 2010 13:17, Robert Haas <robertmhaas@gmail.com> wrote: >>> On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown <thom@linux.com> wrote: >>>> At the moment, to enable logging, a service restart is required. Is >>>> there any way to remove this requirement or is there a fundamental >>>> reason why it must always be like that? >>> >>> Are you speaking of the logging_collector GUC? I think the difficulty >>> is - if you wanted to turn this on without a restart, how would you >>> get the collector's stdin to be each backend's stdout/stderr? I don't >>> see any way to do it, actually. >> >> This is probably blasphemy, but "off" would log to a symbolic link >> pointing to /dev/null, which is repointed to a log_file if reloaded >> with "on"? > > No, this is horrible. I take it back. :-) It would be very nice to figure out a clever way to fix this. Maybe you could do something like create the logging pipe and pass the fd down to all the children even if the logging collector is turned off. Then they can use dup2() to switch around their fds between their original stdout and the logging pipe if the collector is turned on or off. Except that wouldn't actually work for switching the collector off, because the collector can't exit if anyone still has the fd open, and if the children closed the fd then you'd be hosed the next time the collector got turned back on. Maybe there's a way to use a named pipe or a socket or something. <waves hands, wanders off muttering> -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On 09/24/2010 08:22 AM, Thom Brown wrote: > On 24 September 2010 13:17, Robert Haas<robertmhaas@gmail.com> wrote: >> On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown<thom@linux.com> wrote: >>> At the moment, to enable logging, a service restart is required. Is >>> there any way to remove this requirement or is there a fundamental >>> reason why it must always be like that? >> Are you speaking of the logging_collector GUC? I think the difficulty >> is - if you wanted to turn this on without a restart, how would you >> get the collector's stdin to be each backend's stdout/stderr? I don't >> see any way to do it, actually. > This is probably blasphemy, but "off" would log to a symbolic link > pointing to /dev/null, which is repointed to a log_file if reloaded > with "on"? No, off simply means we aren't collecting the log, not that we aren't producing any. All the buildfarm tests run without using the logging collector, but they DO produce logs :-) What's the use case for making it settable on the fly? I can't see that this is worth the probably quite large amount of coding that would be required. cheers andrew
On 24 September 2010 16:52, Andrew Dunstan <andrew@dunslane.net> wrote: > > > On 09/24/2010 08:22 AM, Thom Brown wrote: >> >> On 24 September 2010 13:17, Robert Haas<robertmhaas@gmail.com> wrote: >>> >>> On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown<thom@linux.com> wrote: >>>> >>>> At the moment, to enable logging, a service restart is required. Is >>>> there any way to remove this requirement or is there a fundamental >>>> reason why it must always be like that? >>> >>> Are you speaking of the logging_collector GUC? I think the difficulty >>> is - if you wanted to turn this on without a restart, how would you >>> get the collector's stdin to be each backend's stdout/stderr? I don't >>> see any way to do it, actually. >> >> This is probably blasphemy, but "off" would log to a symbolic link >> pointing to /dev/null, which is repointed to a log_file if reloaded >> with "on"? > > No, off simply means we aren't collecting the log, not that we aren't > producing any. All the buildfarm tests run without using the logging > collector, but they DO produce logs :-) > > What's the use case for making it settable on the fly? I can't see that this > is worth the probably quite large amount of coding that would be required. A very busy server you can't afford to have down. There's a server at work which serves a lot of clients and it's always busy. An attempt to restart would be waiting for running queries to finish while denying new connections, and during this time, web applications dependent on it are non-functional. I noticed we weren't logging on that server and needed to enable it. In this case I've changed the config to the required setting, but won't take effect until one of those rare times when we restart the daemon or server. But the problem now is, in the meantime, if something goes wrong, I won't be able to see exactly what. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935