On Wed, Aug 27, 2014 at 12:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote: >> Stephen Frost <sfr...@snowman.net> writes: >>> Consider an audit system where which columns end up in the audit log are >>> controlled by issuing ALTER TABLE .. ALTER COLUMN type statements. > >> I'd like to consider such a thing, but it seems like utter pie in the >> sky. > > On further thought: the existing postmaster log is primarily an error log, > and for the reasons I mentioned, it seems useless to imagine filtering it > on security-based grounds. You can either route it to /dev/null or > restrict viewing to suitably privileged people; there is no middle ground > with any usefulness. > > However: for some values of "audit" it seems like an audit log could > consist of reports of changes actually applied to the database. If that's > your definition then it's surely possible to imagine omitting particular > columns (or rows) from the output, because we've already eliminated all > the cases where the system couldn't make sense of the input it was fed. > So I think Alvaro was right to suggest that maybe the logical-decoding > subsystem, rather than the existing logging subsystem, is where to look > for solutions. You could do logical decoding of changes and emit a > filtered version of that to some output that's independent of the current > postmaster logging arrangements.
There is a case where read query not generating WAL needs to be audited (e.g., a user might want to audit any queries accessing the table which contains credit card number). So I doubt if logical decoding is really good answer for the audit. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
