On Sat, Apr 28, 2012 at 03:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Josh Berkus <josh@agliodbs.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. =A0Another 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?). =A0Neither 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... ] =A0A 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. =A0We'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?
--=20
=A0Magnus Hagander
=A0Me: http://www.hagander.net/
=A0Work: http://www.redpill-linpro.com/