Re: replication commands and log_statements
От | Robert Haas |
---|---|
Тема | Re: replication commands and log_statements |
Дата | |
Msg-id | CA+TgmoYuOxBWKkwr_noDH_Zu+Mgj+OmpKjTO-7jGH8LLVaNL-g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: replication commands and log_statements (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: replication commands and log_statements
|
Список | pgsql-hackers |
On Mon, Jun 23, 2014 at 11:15 AM, Stephen Frost <sfrost@snowman.net> wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> Similarly, >> building a logging facility that meets the needs of real users is >> going to require a configuration method more flexible than a total >> order with four choices. I happen to think a list of comma-separated >> tokens is a pretty good choice, but something else could be OK, too. >> We need something better than what we've got now, though. > > Absolutely, and not all of that should be done through postgresql.conf, > imv. The level of flexibility that is being asked for, from what I've > seen and heard, really needs to be met with new catalog tables or > extending existing ones. The nearby thread on pg_audit would be a good > example. > > I certainly don't want to be specifying specific table names or > providing a list of roles through any GUC (or configuration file of any > kind). I'm not adverse to improving log_statement to a list with tokens > that indicate various meaning levels but anything done through that > mechanism will be very coarse. True, but it would be enough to let you make a list of commands you'd like to audit, and I think that might be valuable enough to justify the price of admission. I certainly agree that logging based on which object is being accessed needs a different design, tied into the catalogs. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: