Re: Expose checkpoint start/finish times into SQL.
От | Andrew Dunstan |
---|---|
Тема | Re: Expose checkpoint start/finish times into SQL. |
Дата | |
Msg-id | 47F587E0.3060106@dunslane.net обсуждение исходный текст |
Ответ на | Re: Expose checkpoint start/finish times into SQL. ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: Expose checkpoint start/finish times into SQL.
|
Список | pgsql-patches |
Joshua D. Drake wrote: >>> Exposing everything into the log files isn't always sufficient >>> (says the guy who maintains a remote admin tool) >>> >>> >> It should be now that you can have machine readable logs (says the >> guy who literally spent weeks making that happen) ;-) >> > > And how does the person get access to those? And what script do I need > to write to make it happen? Don't get me wrong, the feature you worked > entirely too hard on to get working is valuable but... being able to > say, "SELECT * FROM give_me_my_db_info;" is much more useful in this > context. > How to load the CSV logs is very clearly documented. It's really *very* easy, so easy it's mostly C&P. See http://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG If you are trying to tell me that that's too hard for a DBA, then I have to say you need better DBAs. > In short, I should never have to go to log for this class of > information. It should be available in the database. > > What you haven't explained is why this information needs to be kept in the db on a historical basis, as opposed to all the other possible diagnostics where history might be useful (and, as Tom has pointed out, this patch doesn keep it historically any way). I think there is quite possibly a good case for keeping some diagnostics in a table or tables, on a rolling basis, maybe. But then that's a facility that needs to be properly designed. cheers andrew
В списке pgsql-patches по дате отправления: