Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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
The Enterprise Postgres Company

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group