Re: replication commands and log_statements - Mailing list pgsql-hackers

From Robert Haas
Subject Re: replication commands and log_statements
Date
Msg-id CA+TgmoYuOxBWKkwr_noDH_Zu+Mgj+OmpKjTO-7jGH8LLVaNL-g@mail.gmail.com
Whole thread Raw
In response to Re: replication commands and log_statements  (Stephen Frost <sfrost@snowman.net>)
Responses Re: replication commands and log_statements  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Atomics hardware support table & supported architectures
Next
From: Andrew Dunstan
Date:
Subject: Re: please review source(SQLServer compatible)‏