[HACKERS] Enable logging requires restart

2010-09-24 Thread Thom Brown
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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Enable logging requires restart

2010-09-24 Thread Robert Haas
On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown t...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Enable logging requires restart

2010-09-24 Thread Thom Brown
On 24 September 2010 13:17, Robert Haas robertmh...@gmail.com wrote:
 On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown t...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Enable logging requires restart

2010-09-24 Thread Thom Brown
On 24 September 2010 13:22, Thom Brown t...@linux.com wrote:
 On 24 September 2010 13:17, Robert Haas robertmh...@gmail.com wrote:
 On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown t...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Enable logging requires restart

2010-09-24 Thread Robert Haas
On Fri, Sep 24, 2010 at 8:31 AM, Thom Brown t...@linux.com wrote:
 On 24 September 2010 13:22, Thom Brown t...@linux.com wrote:
 On 24 September 2010 13:17, Robert Haas robertmh...@gmail.com wrote:
 On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown t...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Enable logging requires restart

2010-09-24 Thread Andrew Dunstan



On 09/24/2010 08:22 AM, Thom Brown wrote:

On 24 September 2010 13:17, Robert Haasrobertmh...@gmail.com  wrote:

On Fri, Sep 24, 2010 at 4:33 AM, Thom Brownt...@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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Enable logging requires restart

2010-09-24 Thread Thom Brown
On 24 September 2010 16:52, Andrew Dunstan and...@dunslane.net wrote:


 On 09/24/2010 08:22 AM, Thom Brown wrote:

 On 24 September 2010 13:17, Robert Haasrobertmh...@gmail.com  wrote:

 On Fri, Sep 24, 2010 at 4:33 AM, Thom Brownt...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers