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

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension
Дата
Msg-id 20150528020201.GQ26667@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension  ("Joshua D. Drake" <jd@commandprompt.com>)
Список pgsql-hackers
JD,

* Joshua D. Drake (jd@commandprompt.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1