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@2ndQuadrant.com www.2ndQuadrant.us
