> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Monday, April 20, 2009 6:28 PM > To: rsyslog-users > Subject: Re: [rsyslog] RFC: On rsyslog output modules and support for > batchoperations > > On Mon, 20 Apr 2009, Rainer Gerhards wrote: > > > David, > >> every database that I have seen (including Oracle) has had the > ability > >> to > >> create prepared statements and stored procedures from the text-based > >> database tool, so I'm not understanding why working with 'just > strings' > >> isn't enough. could you explain more? > >> > > > > While this is not really nice, let me ask a counter-question: how is > this > > done for example in Oracle? All I have seen while reviewing manuals > was that > > you need to call a series of APIs. Most importantly usually one where > you > > specify buffer sizes - what is real pain, given the fact that we do > not > > really want to be able to use this jumbo buffers just because there > is an > > ultra-slim chance we may have one message per year that is that large > (but > > that's another issue, let's not get to distracted at this point). > > I'll ask the Oracle experts here at work.
Excellent, but let me re-phrase: if you have a PostgreSQL expert at hand, that would be even more useful (I can do testing with PostgreSQL myself, but do not have access to Oracle - I overlooked that tiny little restriction when posting ;)). Rainer > > David Lang > > > [snip] > > > >> definantly making the queue support batches ;-) > >> > >> as I see it, that will benifit all output modules, not just the DB > >> ones. > >> and you are the only person who can do the queue support while there > >> are > >> others who can (and do) work on the DB modules themselves. > >> > >> I would expect it to take a bit of 'discussion' between the > different > >> DB > >> folks for them to all agree on any new abstraction, no it's not > >> something > >> that can be started immediatly in any case. > > > > Unfortunately there are not that many *active* db folks. I guess n=2, > me > > included ;) > > > > Anyhow, that doesn't mean it has priority. But the two issues, as I > now see > > it, are entangled. For the queue optimization, I need a test > environment and > > it better be a good one. File output is too fast to be a good one. > Database > > output is perfect. So I would actually need to modify at least one db > output > > to support the queue enhancements. Plus, that will actually tell me > the fine > > print of enhancing the queue in the best possible way. I've started > to look > > at the postgres module for that reason. Thinking over the situation, > I then > > found out that what I am doing now is exactly the same thing, with > exactly > > the same issues, that Luis Fernando does with Oracle. This cries for > a > > generic approach, especially if it is not too much effort to > generalize. > > > > The macro-approach goes into that direction: keep it simple, but > don't go the > > full length of a minidriver model. > > > > Rainer > >> > >> David Lang > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
