Re: log_collector doesn't respond to reloads
От | Magnus Hagander |
---|---|
Тема | Re: log_collector doesn't respond to reloads |
Дата | |
Msg-id | CABUevEzVaY9Ntev=+3VHQW3mgZx4ua8dHEMZioR9tDg8+HBUQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: log_collector doesn't respond to reloads (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: log_collector doesn't respond to reloads
|
Список | pgsql-bugs |
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/
В списке pgsql-bugs по дате отправления: