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
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
