Re: Enable logging requires restart

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thom Brown <thom(at)linux(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Enable logging requires restart
Date: 2010-09-24 12:53:02
Message-ID: AANLkTik60yfROOAq4_1mCM9byYGnsXyj38VejEBQGU-e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 24, 2010 at 8:31 AM, Thom Brown <thom(at)linux(dot)com> wrote:
> On 24 September 2010 13:22, Thom Brown <thom(at)linux(dot)com> wrote:
>> On 24 September 2010 13:17, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Fri, Sep 24, 2010 at 4:33 AM, Thom Brown <thom(at)linux(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2010-09-24 12:54:21 Re: security label support, revised
Previous Message Robert Haas 2010-09-24 12:38:15 Re: Configuring synchronous replication