On Fri, Feb 19, 2016 at 08:20:31AM -0800, Andres Freund wrote:
> On 2016-02-19 10:14:47 -0500, Bruce Momjian wrote:
> > We have already hesitated to record DDL changes for
> > logical replication because of the code size, maintenance overhead, and
> > testing required.
>
> I'm not sure what you're
On Fri, Feb 19, 2016 at 11:20:13AM -0500, David Steele wrote:
> On 2/19/16 10:54 AM, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> >> Understood. My point is that there is a short list of read events, and
> >> many DDL events. We have already hesitated to record DDL changes for
> >> logic
On 2016-02-19 10:14:47 -0500, Bruce Momjian wrote:
> We have already hesitated to record DDL changes for
> logical replication because of the code size, maintenance overhead, and
> testing required.
I'm not sure what you're referring to here? It'd be some relatively
minor code surgery to also pass
On 2/19/16 10:54 AM, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
>> Understood. My point is that there is a short list of read events, and
>> many DDL events. We have already hesitated to record DDL changes for
>> logical replication because of the code size, maintenance overhead, and
>> test
On Fri, Feb 19, 2016 at 12:54:17PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Understood. My point is that there is a short list of read events, and
> > many DDL events. We have already hesitated to record DDL changes for
> > logical replication because of the code size, maintenan
Bruce Momjian wrote:
> Understood. My point is that there is a short list of read events, and
> many DDL events. We have already hesitated to record DDL changes for
> logical replication because of the code size, maintenance overhead, and
> testing required.
DDL is already captured using the ev
On 2/19/16 10:14 AM, Bruce Momjian wrote:
> On Fri, Feb 19, 2016 at 09:19:58AM -0500, David Steele wrote:
>>> I was suggesting we could track write events via logical replication and
>>> then we only have to figure out auditing of read events, which would be
>>> easier.
>>
>> I agree that DDL/DML a
On Fri, Feb 19, 2016 at 09:19:58AM -0500, David Steele wrote:
> > I was suggesting we could track write events via logical replication and
> > then we only have to figure out auditing of read events, which would be
> > easier.
>
> I agree that DDL/DML audit logging requires a lot of the same
> inf
On 2/17/16 10:25 PM, Bruce Momjian wrote:
> On Wed, Feb 17, 2016 at 01:59:09PM +0530, Robert Haas wrote:
>> On Wed, Feb 17, 2016 at 5:20 AM, Bruce Momjian wrote:
>>> On Fri, Feb 5, 2016 at 01:16:25PM -0500, Stephen Frost wrote:
Looking at pgaudit and the other approaches to auditing which ha
On Wed, Feb 17, 2016 at 01:59:09PM +0530, Robert Haas wrote:
> On Wed, Feb 17, 2016 at 5:20 AM, Bruce Momjian wrote:
> > On Fri, Feb 5, 2016 at 01:16:25PM -0500, Stephen Frost wrote:
> >> Looking at pgaudit and the other approaches to auditing which have been
> >> developed (eg: applications whic
On Wed, Feb 17, 2016 at 5:20 AM, Bruce Momjian wrote:
> On Fri, Feb 5, 2016 at 01:16:25PM -0500, Stephen Frost wrote:
>> Looking at pgaudit and the other approaches to auditing which have been
>> developed (eg: applications which sit in front of PG and essentially
>> have to reimplement large bit
On Fri, Feb 5, 2016 at 01:16:25PM -0500, Stephen Frost wrote:
> Looking at pgaudit and the other approaches to auditing which have been
> developed (eg: applications which sit in front of PG and essentially
> have to reimplement large bits of PG to then audit the commands sent
> before passing the
On Fri, Feb 5, 2016 at 1:16 PM, Stephen Frost wrote:
> An in-core auditing solution would provide us with proper grammar
> support, ability to directly mark objects for auditing in the catalog,
> allow us to much more easily maintain auditing capability over time as
> a small incremental bit of wo
* Joe Conway (m...@joeconway.com) wrote:
> On 02/05/2016 10:16 AM, Stephen Frost wrote:
> > An in-core auditing solution would provide us with proper grammar
> > support, ability to directly mark objects for auditing in the catalog,
> > allow us to much more easily maintain auditing capability over
On 02/05/2016 10:16 AM, Stephen Frost wrote:
> An in-core auditing solution would provide us with proper grammar
> support, ability to directly mark objects for auditing in the catalog,
> allow us to much more easily maintain auditing capability over time as
> a small incremental bit of work for ea
All,
* Robert Haas (robertmh...@gmail.com) wrote:
> OK, I'll bite: I'm worried that this patch will be a maintenance
> burden. It's easy to imagine that changes to core will result in the
> necessity or at least desirability of changes to pgaudit, but I'm
> definitely not prepared to insist that
Jim Nasby writes:
> As for PGXN being an untrusted source, that's something that it's in the
> project's best interest to try and address somehow, perhaps by having
> formally audited extensions. Amazon already has to do this to some
> degree before an extension can be allowed in RDS, and so do
On 2/3/16 10:36 AM, Robert Haas wrote:
People who are interested in audit are also understandably leery of
>downloading code from an untrusted source. Both PGXN and GitHub are The
>Wild West as far as conservative auditors are concerned.
I hate to be rude here, but that's not my problem. You c
On 2/3/16 11:36 AM, Robert Haas wrote:
> That's good to hear, but again, it's not enough for a core submission.
> Code that goes into our main git repository needs to be "the
> prettiest". I mean it's not all perfect of course, but it should be
> pretty darn good.
I still think it's pretty darn
On 02/03/2016 10:36 AM, Robert Haas wrote:
I'll be the first to admit that the design is not the prettiest. Trying
It's entirely reasonable for the community NOT to want to
privilege one implementation over another.
This, not so much.
No, this is ABSOLUTELY critical. Suppose EnterpriseDB
On Wed, Feb 3, 2016 at 12:38 PM, David G. Johnston
wrote:
>> Right now that may be true, although it wouldn't surprise me very much
>> to find out that other people have written such extensions and they
>> just didn't get as much press. Also, consider the future. It is
>> *possible* that your ve
On Wed, Feb 3, 2016 at 9:36 AM, Robert Haas wrote:
> On Wed, Feb 3, 2016 at 10:37 AM, David Steele wrote:
> > On 2/1/16 11:23 PM, Robert Haas wrote:
>
> >> In
> >> saying that it's arbitrary, I'm not saying it isn't *useful*. I'm
> >> saying there could be five extensions like this that make eq
On Wed, Feb 3, 2016 at 10:37 AM, David Steele wrote:
> On 2/1/16 11:23 PM, Robert Haas wrote:
>> OK, I'll bite: I'm worried that this patch will be a maintenance
>> burden. It's easy to imagine that changes to core will result in the
>> necessity or at least desirability of changes to pgaudit, bu
Hi Robert,
Thank you for replying.
On 2/1/16 11:23 PM, Robert Haas wrote:
> OK, I'll bite: I'm worried that this patch will be a maintenance
> burden. It's easy to imagine that changes to core will result in the
> necessity or at least desirability of changes to pgaudit, but I'm
> definitely not
On 02/01/2016 08:23 PM, Robert Haas wrote:
It also appears to me that if we did want to do that, it would need
quite a lot of additional cleanup. I haven't dug in enough to have a
list of specific issues, but it does look to me like there would be
quite a bit. Maybe that'd be worth doing if th
On Sun, Jan 31, 2016 at 5:19 PM, Alvaro Herrera
wrote:
> Joshua D. Drake wrote:
>> On 01/31/2016 05:07 AM, Alvaro Herrera wrote:
>> >David Steele wrote:
>> >>The attached patch implements audit logging for PostgreSQL as an
>> >>extension. I believe I have addressed the concerns that were raised a
On Mon, Feb 01, 2016 at 09:59:01PM +0100, Alvaro Herrera wrote:
> Anyway I think the tests here are massive
I would not want to see fewer tests. When I reviewed a previous incarnation
of pgaudit, the tests saved me hours of writing my own.
> and the code is not;
Nah; the patch size category is
On 2/1/16 4:19 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Anyway I think the tests here are
>> massive and the code is not; perhaps people get the mistaken impression
>> that this is a huge amount of code which scares them. Perhaps you could
>> split it up in (1) code and (2) tests, wh
[I pulled this back in from the other thread that got started. This
happened because my email to pgsql-hackers bounced but was also sent to
Alvaro who replied to that message not the later one that went through
to hackers.]
On 2/1/16 3:59 PM, Alvaro Herrera wrote:
> Anyway, what would *you* do wi
Alvaro Herrera writes:
> Anyway I think the tests here are
> massive and the code is not; perhaps people get the mistaken impression
> that this is a huge amount of code which scares them. Perhaps you could
> split it up in (1) code and (2) tests, which wouldn't achieve any
> technical bene
David Steele wrote:
> On 1/31/16 8:07 AM, Alvaro Herrera wrote:
> > I'm giving
> > this patch some more time by moving it to next commitfest instead.
>
> I was under the mistaken impression that the CF was two months long so I
> appreciate getting a little more time.
Yeah, sorry to disappoint bu
On 1/31/16 8:07 AM, Alvaro Herrera wrote:
> David Steele wrote:
>> The attached patch implements audit logging for PostgreSQL as an
>> extension. I believe I have addressed the concerns that were raised at
>> the end of the 9.5 development cycle.
>
> This patch got no feedback at all during the c
Joshua D. Drake wrote:
> On 01/31/2016 05:07 AM, Alvaro Herrera wrote:
> >David Steele wrote:
> >>The attached patch implements audit logging for PostgreSQL as an
> >>extension. I believe I have addressed the concerns that were raised at
> >>the end of the 9.5 development cycle.
> >
> >This patch
On 01/31/2016 05:07 AM, Alvaro Herrera wrote:
David Steele wrote:
The attached patch implements audit logging for PostgreSQL as an
extension. I believe I have addressed the concerns that were raised at
the end of the 9.5 development cycle.
This patch got no feedback at all during the commitfe
David Steele wrote:
> The attached patch implements audit logging for PostgreSQL as an
> extension. I believe I have addressed the concerns that were raised at
> the end of the 9.5 development cycle.
This patch got no feedback at all during the commitfest. I think there
is some interest on audit
35 matches
Mail list logo