the lack of a true full audit trail capabiity in postgres is perhaps
it's biggest fundamental weakness as a "commercial" use system
it has "commercial" use viability at this moment like the XT had
"commercial" use viabilty in the early 80's
ie it's demand driven in a market where many (un aware or unconcrned)
people/businesses are prepared to pay for something that's really not
the real thing (hope i havn't broken and stupid copyright laws there)
in fact. if i was to want to design a database system for "commercial"
use the very first thing i would start with would be the audit system
objects oriented? no, after audit
referenential integrety?, no, after audit
really - even just on a practicality basis the audit is essential
there needs to be a front end to the database - a completely new layer -
that layer feeds the database and no other and that layer is itself the
it should be possible to run an audit trail backwards against a database
and undo everything back to an earlier state (assuming that this is done
in standalone mode)
the audit then IS the database - or rather it IS the data - all of it -
and ideally it wold be in a form that is almost human readable
Justin Clift wrote:
>I can see the usefulness of this concept from a "Data Security" point of
>At one place I worked, it was known one of the marketing people had a
>reputation of gathering customer details before leaving a job, just so
>he had something to bargain a pay increase with for his next job. Don't
>know why people hire a guy like that (I wouldn't), but these people
>It should definitely be optional, and if not turned on for an object I
>don't think it should have an associated noticable performance penalty.
>My thought is useful, but not sure how urgent when compared to other
>Gavin Sherry wrote:
>>I've been thinking implementing auditing for Postgres 7.3 and wanted to
>>see if anyone had any thoughts about it.
>>Auditing would allow a user to log queries executed upon different
>>'schema' objects - I use the loose sense of the word here. The user would
>>be able to define the type of query - insert, delete, etc - as well as
>>choose to log only those queries which were successful or otherwise.
>>The superuser would be able to audit unprivileged users. Unprivileged
>>users would only be able to produce an audit trail upon objects which
>>he/she owns or has been granted audit privileges to.
>>The audit trail would be written either to a new internal system table,
>>pg_audit, or optionally a file on the file system. I imagine that an
>>external program would also be needed to read/dump the audit trail.
>>So what would an audit trail consist of?
>>query result (successful|unsuccessful)
>>audit object oid
>>I haven't really thought about this too hard just yet but thought I'd see
>>if people considered this to be a useful addition to Postgres or not, or
>>if I was going about this the wrong way.
>>---------------------------(end of broadcast)---------------------------
>>TIP 4: Don't 'kill -9' the postmaster
In response to
pgsql-hackers by date
|Next:||From: Gavin Sherry||Date: 2002-01-23 13:01:21|
|Subject: Re: Auditing and Postgres 7.3|
|Previous:||From: Lamar Owen||Date: 2002-01-23 12:49:36|
|Subject: Red Hat 7.2 Regression failures (Re: pltcl build problem on FreeBSD (was: Re: pltlc and pltlcu problems))|