Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> At least on dromedary, this seems to be the problem: >> >> pg_audit.c: In function 'stack_pop': >> pg_audit.c:387: warning: format '%ld' expects type 'long int', but argument >> 3 has type 'int64' >> pg_audit.c: In function 'stack_valid': >> pg_audit.c:406: warning: format '%ld' expects type 'long int', but argument >> 3 has type 'int64' >> pg_audit.c:406: warning: format '%ld' expects type 'long int', but argument >> 4 has type 'int64' >> pg_audit.c: In function 'log_audit_event': >> pg_audit.c:676: warning: format '%ld' expects type 'long int', but argument >> 4 has type 'int64' >> pg_audit.c:676: warning: format '%ld' expects type 'long int', but argument >> 5 has type 'int64' >> >> Will push a fix shortly and we'll see what happens.
> Ah, ok. Pushed that, but some further notes: * The actual audit reports ought to be ereport() not elog(). I made them so but did not insert an errcode(). ISTM that it would likely be a good thing to assign a not-used-for-any-other-purpose errcode for this, but I'm not terribly sure what category to put it in. * The comments in the code betray utter ignorance of how logging actually works, in particular this: * Administrators can choose which log level the audit log is to be logged * at. The default level is LOG, which goes into the server log but does * not go to the client. Set to NOTICE in the regression tests. All the user has to do is change client_min_messages and he'll see all the reports, which means if you think that letting the user see the audit reports is a security problem then you have a hole a mile wide. (I assume BTW that we're not considering it a security problem that superusers can trivially escape auditing.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers