Re: pgaudit - an auditing extension for PostgreSQL
От | Fujii Masao |
---|---|
Тема | Re: pgaudit - an auditing extension for PostgreSQL |
Дата | |
Msg-id | CAHGQGwEbuOihJ3C9rOEFLVsVjgiwSvHM9-ytC6zx4+bjBaP7qA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgaudit - an auditing extension for PostgreSQL (David Steele <david@pgmasters.net>) |
Ответы |
Re: pgaudit - an auditing extension for PostgreSQL
|
Список | pgsql-hackers |
On Wed, Feb 18, 2015 at 1:26 AM, David Steele <david@pgmasters.net> wrote: > On 2/17/15 10:23 AM, Simon Riggs wrote: >> I vote to include pgaudit in 9.5, albeit with any changes. In >> particular, David may have some changes to recommend, but I haven't >> seen a spec or a patch, just a new version of code (which isn't how we >> do things...). > > I submitted the new patch in my name under a separate thread "Auditing > extension for PostgreSQL (Take 2)" (54E005CC.1060605@pgmasters.net) I played the patch version of pg_audit a bit and have basic comments about its spec. The pg_audit doesn't log BIND parameter values when prepared statement is used. Seems this is an oversight of the patch. Or is this intentional? The pg_audit cannot log the statement like "SELECT 1" which doesn't access to the database object. Is this intentional? I think that there are many users who want to audit even such statement. Imagine the case where you call the user-defined function which executes many nested statements. In this case, pg_audit logs only top-level statement (i.e., issued directly by client) every time nested statement is executed. In fact, one call of such UDF can cause lots of *same* log messages. I think this is problematic. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: