On Fri, Feb 19, 2016 at 09:19:58AM -0500, David Steele wrote: > > I was suggesting we could track write events via logical replication and > > then we only have to figure out auditing of read events, which would be > > easier. > > I agree that DDL/DML audit logging requires a lot of the same > information as logical replication but I don't think reading the logical > WAL stream is a good way to do audit logging even for writes. > > For instance there are some "writes" that are not WAL logged such as SET > or ALTER SYSTEM. Determining attribution would be difficult or > impossible, such as which function called an update statement (or vice > versa). Tying together the read and write information would be tricky > as well since the WAL stream contains information on transactions but > not user sessions, if I understand it correctly. > > The end result is that it would be very difficult to record a coherent, > attributed, and sequential audit log and in fact represent a step > backward from pgaudit's current capabilities.
Understood. My point is that there is a short list of read events, and many DDL events. We have already hesitated to record DDL changes for logical replication because of the code size, maintenance overhead, and testing required. If we could use the same facility for both logical replication and auditing, the cost overhead is less per feature. For example, we don't need to read the WAL to do the auditing, but the same facility could be used for both, e.g. output some JSON standard format that both logical replication and auditing could understand. The bottom line is we need to crack the record-DDL nut somehow, and at least in this case, we have two use-cases for it. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
