Re: Auditing extension for PostgreSQL (Take 2)

* Peter Eisentraut (peter_e@gmx.net) wrote:
> On 5/4/15 8:37 PM, Stephen Frost wrote:
> > I don't follow this logic.  The concerns raised above are about changing
> > our in-core logging.  We haven't got in-core auditing and so I don't see
> > how they apply to it.
>
> How is session "auditing" substantially different from statement logging?

David had previously outlined the technical differences between the
statement logging we have today and what pgAudit does, but I gather
you're asking about it definitionally, though it ends up amounting to
much the same to me.  Auditing is about "what happened" whereas
statement logging is "log whatever statement the user sent."  pgAudit
bears this out by logging internal SQL statements and object
information, unlike what we do with statement logging today.

> I think it is not, and we could tweak the logging facilities a bit to
> satisfy the audit trail case while making often-requested enhancement to
> the traditional logging use case as well at the same time.

Changing our existing statement logging to be a "what happened" auditing
system is possible, but I don't see it as a "tweak."

> At least no one has disputed that yet.  The only argument against has
> been that they don't want to touch the logging.

I'm afraid we've been talking past each other here- I'm fully on-board
with enhancing our in-core logging capabilities and even looking to the
future at having object auditing included in core.  It's not my intent
to dispute that or to argue against it.

Perhaps I've misunderstood the thrust of this sub-thread, so let me
explain what I thought the discussion was.  My understanding was that
you were concerned about having session auditing included in pgAudit
and, further, that you wanted to see our in-core statement logging be
improved.  I agree that we want to improve the in-core statement logging
and, ideally, have an in-core auditing solution in the future.  I was
attempting to address the concern about having session logging in
pgAudit by pointing out that it's valuable to have even if our in-core
statement logging is augmented, and further, having it in pgAudit does
not preclude or reduce our ability to improve the in-core statement
logging in the future; indeed, it's my hope that we'll get good feedback
from users of pgAudit which could guide our in-core implementation.  As
for the concern that pgAudit may end up "rotting" in the tree as some
other contrib modules have, I can say with confidence that we will have
users of it just as soon as they're able to move to a version of PG
which includes it and therefore will be supporting it and addressing
issues as we discover them, as I suspect the others who have been
involved in this discussion will be also.  Additionally, as discussed
last summer, we can provide a migration path (which does not need to be
automated or even feature compatible) from pgAudit to an in-core
solution and then sunset pgAudit.

Building an in-core solution, in my estimation at least, is going to
require at least a couple of release cycles and having the feedback from
users of pgAudit will be very valuable to building a good solution, but
I don't believe we'll get that feedback without including it.

Lastly, from the perspective of the session logging piece, the code
footprint for that in pgAudit isn't the bulk or even terribly
significant, most of the code would still be required for the object
auditing capability.
Thanks!
    Stephen