Re: pgaudit - an auditing extension for PostgreSQL
От | Stephen Frost |
---|---|
Тема | Re: pgaudit - an auditing extension for PostgreSQL |
Дата | |
Msg-id | 20140730182947.GC16422@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: pgaudit - an auditing extension for PostgreSQL (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: pgaudit - an auditing extension for PostgreSQL
Re: pgaudit - an auditing extension for PostgreSQL Re: pgaudit - an auditing extension for PostgreSQL |
Список | pgsql-hackers |
* Bruce Momjian (bruce@momjian.us) wrote: > Actually, thinking more, Stephen Frost mentioned that the auditing > system has to modify database _state_, and dumping/restoring the state > of an extension might be tricky. This is really true of any extension which wants to attach information or track things associated with roles or other database objects. What I'd like to avoid is having an extension which does so through an extra table or through reloptions or one of the other approaches which exists in contrib and which implements a capability we're looking at adding to core as we'd then have to figure out how to make pg_upgrade deal with moving such a configuration from the extension's table or from reloptions into SQL commands which work against the version of PG which implements the capability in core. Using auditing as an example, consider this scenario: pgaudit grows a table which is used to say "only audit roles X, Y, Z" (or specific tables, or connections from certain IPs,etc). A patch for PG 10.1 is proposed which adds the ability to enable auditing for specific roles. My concern is: pg_upgrade then has to detect, understand, and implement a migration path from 10.0-with-pgaudit to 10.1-in-core-auditing. or The PG 10.1 patch has to ensure that it doesn't break, harm, or interfere with what pgaudit is doing in its per-role auditing. or The PG 10.1 patch is bounced because what pgaudit does is considered "good enough" and it's already in contrib (though Idon't believe this will ever be the case while pgaudit exists as an extension- see below). From my perspective, it's pretty clear that we don't have any good way for any extension, today, to have metadata properly associated with database objects- such that renames, upgrades, dependency issues, etc, are properly addressed and handled; nor are extensions able to extend the grammar; and there is a concern that extensions may not always be properly loaded, a serious concern when the role of that extension is auditing. Hope that helps. Thanks, Stephen
В списке pgsql-hackers по дате отправления: