-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 4/6/15 4:47 PM, Simon Riggs wrote: > On 6 April 2015 at 16:34, Peter Eisentraut <pete...@gmx.net> > wrote: >> "Audit" is a "big word". It might imply regulatory or standards >> compliance on some level. We already have ways to log >> everything. If customers want "auditing" instead, they will >> hopefully have a precise requirements set, and we need a way to >> map that to a system configuration. I don't think "we need >> auditing" -> "oh there's this pg_audit thing, and it has a bunch >> of settings you can play with" is going to be enough of a >> workflow. > > Yes, this needs better documentation, as does RLS.
Discussions like these definitely help when it comes to knowing what to put in the documentation. The "what" is hard enough, the "why" gets into some scary territory. Still, audit requirements vary wildly and I'm not sure how much justice I could do to the topic in the contrib docs. I think more discussion of what's technically possible might be more fruitful. >> For starters, I would consider the textual server log to be >> potentially lossy in many circumstances, so there would need to >> be additional information on how to configure that to be robust. > > It was intended to be used with a log filter plugin, to allow it to > be routed wherever is considered safe. That would certainly work. >> (Also, more accurately, this is an "audit trail", not an "audit". >> An audit is an examination of a system, not a record of >> interactions with a system. An audit trail might be useful for >> an audit.) > > No problem with calling it pg_audit_trail Nor I. >> I see value in what you call object auditing, which is something >> you can't easily do at the moment. But what you call session >> auditing seems hardly distinct from statement logging. If we >> enhance log_statements a little bit, there will not be a need for >> an extra module to do almost the same thing. > > Agreed: generating one line per statement isn't much different > from log_statements. > > The earlier version of pg_audit generated different output. > Specifically, it allowed you to generate output for each object > tracked; one line per object. That is still doable, but is covered by object-level auditing. Even so, multiple log entries are possible (and even likely) with session auditing. See my response to Peter for details. > The present version can trigger an audit trail event for a > statement, without tracking the object that was being audited. This > prevents you from searching for "all SQL that touches table X", > i.e. we know the statements were generated, but not which ones they > were. IMHO that makes the resulting audit trail unusable for > auditing purposes. I would like to see that functionality put back > before it gets committed, if that occurs. Bringing this back would be easy (it actually requires removing, not adding code) but I'd prefer to make it configurable. - -- - - David Steele da...@pgmasters.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVIybuAAoJEIA2uIJQ5SFAm/8P/2gS2oSvxF2VjP3WBJjH0d8p QHlni3SDBIlJPPE1ZnNYbtUANWKSw2Ublpk50223TeejEnNZfORtA7TZ9qic+3Ei 83yK4SzQcSMA1xqMvGTDS621l4/Nkw/uWKO8BDGePTHRjsEPpgMxJxsHVfNddd5Z MTP26vXPgyzj1H1GE4jPCi1kR6iiKx3GiagawmNJNgzdOXf25hQijpQ7mR0puw/T V75MeNr0WNi4CtsyDgNnx0oVKBN4olG6aId6+q3jt+yuxboJ53Nq59xbfvxYUR+3 uPKX9jfwInZxQc+70g2CcKj+EglB9cDn4oaMUkAxqYWKWyRW0O2gs0IIkbQqk8qK SlfBvAaZA1wfDelCztr8GHc8hLIh+hwb3mJq4zoclPg3+36hUgVyVIyRUjzW42sJ shvd2KWkxP4iwN1+tru9YK3qZ1GXkZfodtXdJ7iY14k5eXTKBuRgHFO8BRXxW9xp /KwIgkLD9gEjht6cncgP83lBoaxMFjrQE9N3hzX1wMM5ZYDAisbKK7JkGE2+yCsH L/aiCOxyHbxaMZATopATbCBhULDMLKl9oICKY+jv17yeyGG5F5D78AWv0tuvk1jW 5enydtXPhcBIXRWIvTZgCfDpFs5Hv5r/+V70tiMQbJIzg2qvxHmC0VLEubxky0XE TGfavKbTvK9dmw1dhzk5 =5KkP -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
