Stuart Bishop wrote:
It might be possible to trick csvlog to log to a static filename, and perhaps substituting that with a named pipe might work (under unix at least).
As someone who did a bit of the work on the CSV log feature, I'll tell you the way you have to note the log filename, account for rotations, and everything else involved makes for a painful API to actually use was obvious from day one. What I suggested was that many admins would want a "tail-f like" API available to grabs at they come out, without having to care about the underlying name. But no one has dumped enough development resources into actually building one of them. At the time, there were a host of genuine bugs in the logging approached used for CVS logs, and just closing them all up before release time was difficult enough. And there hasn't been enough asking about it to inspire development since.
I need to be analyzing log messages from PostgreSQL in real time, so am starting to investigate solutions. It seems painful, which would be avoidable for future generations if PostgreSQL could spawn a subprocess and send log messages to that in a machine readable format.
That is the only direction something like this is going to get built in. What Bruce was suggesting is that the idea of building any more logging intelligence into the database itself will never go anywhere. The alternate question of "how do I get a better API for exporting real-time logging messages I can process?" is still quite open in my mind. The idea Magnus was already suggesting here, to add an alternate "pipe" destination, would be one useful step forward here.
-- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@xxxxxxxxxxxxxxx www.2ndQuadrant.us -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
