Re: log_collector doesn't respond to reloads

On Sat, Apr 28, 2012 at 03:35, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> You can end up in a situation where the logs aren't going where they're
>> supposed to due to some external problem, and that the DBA has no way to
>> find out what went wrong because he doesn't know where the logs are *now*.
>
> Well, if nothing else, lsof would help.  Another possibility is that we
> might change the logging collector process to show its current target
> filename in ps status (although might there be security/privacy issues
> with that?).  Neither of those things will help Windows users
> of course, but the sorts of cases you're presenting aren't going to be
> happening on Windows boxes.

We do have the "fake process status kernel object" that can be used as
a last resort. If this is something that would only be used in
debugging scenarios, that would be perfectly reasonable I think.

> [ thinks some more... ]  A lower-tech solution would be to always write
> the name of the current log target file into some small text file in
> $PGDATA.

That seems ugly.

> On the whole though, I think this is an invented problem.  We've never
> heard a complaint from the field about it.

I think process title seems reasonable. We do that for archiver for
example, to tell you where it's writing, don't we?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/