Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension
Date: 2015-05-28 02:02:01
Message-ID: 20150528020201.GQ26667@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

JD,

* Joshua D. Drake (jd(at)commandprompt(dot)com) wrote:
> On 05/27/2015 06:38 PM, Stephen Frost wrote:
> >While I certainly appreciate the support, I don't believe auditing will
> >be able to work as an extension over the long term and if the community
> >is unwilling or unable to accept steps in that direction through contrib
> >modules or even changes to core to improve what we are able to provide
> >in this area,
>
> It seems to me that perhaps the solution is then to pull pg_audit
> into user space and instead work on a general solution (an API?
> custom backend?) that provides what is needed.

I am planning on working on the necessary changes to core to include
auditing capabilities. Hopefully, that will go more smoothly. I do not
believe that auditing should or even can be an external module, indeed,
pg_audit was exactly that attempt and, even with significant resources
put into it over the past year, it falls far short of what any
organization who is familiar with the capabilities in other RDBMSs would
expect. That doesn't mean that I feel it's bad- it's a step in the
right direction, but it isn't a complete solution.

> >I have very serious doubts about the willingness of
> >organizations (particularly those in the financial and government space)
> >to continue to seek out and support PostgreSQL as a viable open source
> >alternative to the commerical RDBMS's which have had these capabilities
> >for years.
>
> This may or may not be true considering and I am not sure it really
> matters in the context of this argument.

I'm confused by this comment. I've had discussions with both financial
and government organizations who are interested in this capability and
have been assured that they are interested in the PostgreSQL community
building and supporting this, and are conversely utterly disinterested
in either commerical or open-source products put out by individual
organizations which can come and go. In my mind, this simply isn't a
question. I wish that everyone could have the same experiences that I
have had and to have been in the discussions that I've been in, but
that's simply impractical and I would hope that my years in this
community would count in my favor when I make these statements.

> >I'm, again, not suggesting that a contrib module is going to be a
> >workable long-term solution for all use-cases, but it would solve quite
> >a few and would be known to be supported, and to have the support of the
> >community, if released as part of PostgreSQL.
>
> If the demand for this module is there, it will receive the support
> it needs regardless if it is in core.

Please see above as I believe it addresses this point.

> >These are extremely
> >serious organizations who care about the reputation of PostgreSQL and
> >the community for delivering quality software. I certainly have no
> >intention to tarnish that in any way as it would be quite detrimental to
> >myself and the community. If that means reverting a patch of my own, or
> >one which I have supported, so be it.
>
> I can not speak to the quality of the patch. I can speak to what
> others, people of repute in this community speak of this patch. The
> leaning tower seems as if it is clearly in the, "we might want to
> think about reverting this".

I have been doing my best to follow all of the comments and concerns
raised regarding this patch. I'm not sure that I share the optimism
that you express in the quote above, but if two other committers feel
that the feature needs to be reverted, then I will revert it. That is
not a documented and formal policy in the community, as far as I'm
aware, but it strikes me as reasonable, in the absence of any obvious
collusion or hidden agendas. Should another committer speak up
regarding the patch, perhaps things would change, but I have no
disillusionment that such will happen in this case and have accepted it.

> As it is currently an extension, it does not need to be in core. If
> this extension reaches a point where it needs to be in core to
> achieve some level of integration not currently provided then we can
> evaluate that problem. Currently, that is not the case.

This simply doesn't make sense- all extensions can hook into the backend
in the same way, regardless of if they are included in the main git repo
or not. Being in the repo represents the support of the overall
community and PGDG, which is, understandably in my view, highly valuable
to the organizations which look to PostgreSQL as an open source
solution for their needs.

Thanks!

Stephen

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Pavel Stehule 2015-05-28 02:46:02 Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension
Previous Message Joshua D. Drake 2015-05-28 01:48:17 Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-05-28 02:14:40 Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Previous Message Robert Haas 2015-05-28 01:52:51 Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1