Auditing extension for PostgreSQL (Take 2) - Mailing list pgsql-hackers
From | David Steele |
---|---|
Subject | Auditing extension for PostgreSQL (Take 2) |
Date | |
Msg-id | 54E005CC.1060605@pgmasters.net Whole thread Raw |
Responses |
Re: Auditing extension for PostgreSQL (Take 2)
(Stephen Frost <sfrost@snowman.net>)
Re: Auditing extension for PostgreSQL (Take 2) (Simon Riggs <simon@2ndQuadrant.com>) Re: Auditing extension for PostgreSQL (Take 2) (Peter Eisentraut <peter_e@gmx.net>) |
List | pgsql-hackers |
I've posted a couple of messages over the last few weeks about the work I've been doing on the pg_audit extension. The lack of response could be due to either universal acclaim or complete apathy, but in any case I think this is a very important topic so I want to give it another try. I've extensively reworked the code that was originally submitted by 2ndQuandrant. This is not an indictment of their work, but rather an attempt to redress concerns that were expressed by members of the community. I've used core functions to determine how audit events should be classified and simplified and tightened the code wherever possible. I've removed deparse and event triggers and opted for methods that rely only on existing hooks. In my last message I provided numerous examples of configuration, usage, and output which I hoped would alleviate concerns of complexity. I've also written a ton of unit tests to make sure that the code works as expected. Auditing has been a concern everywhere I've used or introduced PostgreSQL. Over time I've developed a reasonably comprehensive (but complex) system of triggers, tables and functions to provide auditing for customers. While this has addressed most requirements, there are always questions of auditing aborted transactions, DDL changes, configurability, etc. which I have been unable to satisfy. There has been some discussion of whether or not this module needs to be in contrib. One reason customers trust contrib is that the modules are assumed to be held to a higher standard than code found on GitHub. This has already been pointed out. But I believe another important reason is that they know packages will be made available for a variety of platforms, and bugs are more likely to be experienced by many users and not just a few (or one). For this reason my policy is not to run custom-compiled code in production. This is especially true for something as mission critical as a relational database. I realize this is not an ideal solution. Everybody (including me) wants something that is in core with real policies and more options. It's something that I am personally really eager to work on. But the reality is that's not going to happen for 9.5 and probably not for 9.6 either. Meanwhile, I believe the lack of some form of auditing is harming adoption of PostgreSQL, especially in the financial and government sectors. The patch I've attached satisfies the requirements that I've had from customers in the past. I'm confident that if it gets out into the wild it will bring all kinds of criticism and comments which will be valuable in designing a robust in-core solution. I'm submitting this patch to the Commitfest. I'll do everything I can to address the concerns of the community and I'm happy to provide more examples as needed. I'm hoping the sgml docs I've provided with the patch will cover any questions, but of course feedback is always appreciated. -- - David Steele david@pgmasters.net
Attachment
pgsql-hackers by date: