Re: PostgreSQL Auditing - Mailing list pgsql-hackers
From | Jim Nasby |
---|---|
Subject | Re: PostgreSQL Auditing |
Date | |
Msg-id | 56B15DE3.5000207@BlueTreble.com Whole thread Raw |
In response to | Re: PostgreSQL Auditing (Curtis Ruck <curtis.ruck+pgsql.hackers@gmail.com>) |
List | pgsql-hackers |
On 2/2/16 7:25 PM, Curtis Ruck wrote: > I'm opening to testing and evaluating to see if it meets our compliance > requirements, but I am no where close to being a C developer, or having > C developers that could actually provide a meaningful review. One issue > along this thread already pops up, concerning the client_min_messages, > and how other patches in the pipeline for 9.6 would be required to > enable the auditing to meet compliance requirements. There's other ways you can help besides reviewing. Providing real-world use cases helps. Even better is maintaining things on the wiki that assist with moving things forward (use cases, discussion/decision highlights, really anything that helps move the discussion). > It just seems after reading the mailing list history, that there is a > lack of interest by people with commit authority, even though there is a > decent interest in it from the community, and honestly, no one really > likes auditing, but its one of those damned if you do (in performance) > and damned if you don't (in legal) things. Yeah, no one that's volunteering time (as opposed to being paid to work on PG) is going to pick up something as unsexy and painful to deal with as auditing. > Additionally Robert, given your professional status, you are by no means > an unbiased contributor in this discussion. Your stance on this matter > shows that you don't necessarily want the open source solution to > succeed in the commercial/compliance required space. Instead of arguing I'm sorry, but that's just ridiculous, and I completely agree with Robert's initial sentiment: there needs to be a damn good reason for the community to pick one specific implementation of something when there are competing solutions. > blankly against inclusion can you at least provide actionable based > feedback that if met would allow patches of this magnitude in? It works just like any other patch does: the community has to come to a *consensus* that not only is the feature desired and well designed, but that the implementation is high quality. I haven't followed the auditing discussions closely, but it seems that there are still questions around how the feature should work. > I'm personally fine with fiscally rewarding organizations that assist my > customer in succeeding, but its hard to convince my customer to fund > open source, even though they wouldn't be able to do 75% of what they do > without it. Based on past experience this is the same most open source > organizations face, especially when they don't have the marketing engine > that the large commercial players have. I really don't understand that, given what most of the alternative solutions cost. If they balk at putting money towards developing Postgres they really need to get a quote for running the same amount of MSSQL (let alone Oracle, which is even more expensive). I do think the community could do a better job of at least encouraging companies to fund development. Unfortunately there's always going to be some amount of friction here though, because of the question of how to allocate funds to the different companies that are involved. Another problem is no commercial company can actually guarantee anything will make it into community Postgres, and it's very difficult to even estimate the amount of effort (read as: what to charge) for getting a feature committed. Commercial development is certainly possible though. 2nd Quadrant was able to raise a good amount of money to fund the development of hot standby. IIRC that was before sites like kickstarter existed too, so it would probably be even easier to do today. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
pgsql-hackers by date: