On Wed, Aug 27, 2014 at 12:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Stephen Frost <sfrost@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
