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
