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
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?
In response to
pgsql-bugs by date
|Next:||From: Petteri Räty||Date: 2012-04-28 22:45:37|
|Subject: Re: BUG #6619: Misleading output from slave when host is not
|Previous:||From: Jeff Frost||Date: 2012-04-28 03:02:30|
|Subject: Re: 9.1.3 backends getting stuck in 'startup'|