On Wed, Nov 23, 2011 at 11:45 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> My assumption has been that eventually a lossy logger was going to be
> necessary for busier sites, I just haven't been suffering from one enough to
> hack on it yet. If it's possible to work this out in enough detail to
> figure out where the hooks go, and to prove they work with at least one
> consumer of them, I'd consider that a really useful thing to try and squeeze
> into 9.2.
I think it's possible. I did both in my patches 1) placed hooks where
logging exists today and 2) provided a useful consumer of them. and I
tested it (only on a single system) under high simulated load.
I see the next steps being:1) agreeing that a problem exists (I know one does, but I suppose
consensus is req'd)2) agreeing that "hooks" are the right approach, if not propose a
different approach. (fwiw, it's incredible common)3) reworking the implementation to fit in the project; I assume the
implementation I proposed will, at best, vaguely resemble anything
that gets integrated. It was just a PoC.
Also, I put the sample consumer in contrib in a separate commit, just
to make it easy to review -- while I'm not against it, I am not
proposing that a fifo logger be in contrib.
> The processing parts can always be further improved later based
> on production feedback, going along with my recent them of letting
> extensions that poke and probe existing hooks be one place to brew next
> version features at.
I think that a generalized hook framework (like that offered by
apr-utils) would be generally useful in cases like these. It makes it
simple to add them and auto document them. But, I'm not proposing
that here. I'm trying to keep the patch to logging so I can solve a
critical production issue we seem to be running into more and more.
Thanks for you time.
--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle