Re: Add support for logging the current role

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add support for logging the current role
Date: 2011-01-13 01:16:12
Message-ID: 3235.1294881372@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> Interesting. I wonder if we shouldn't try to fix this by including
>> the relevant role name in the error message. Or is that just going to
>> be too messy to live?

> It might be possible to do and answer that specific question- but what
> about the obvious next question: which role was this command run with?
> iow, if I log dml, how do I know what the role was when the dml
> statement was run? ie- why was this command allowed?

I'm less than excited about that argument because it's after the fact
--- if you needed to know the information, you probably didn't have
log_line_prefix set correctly, even assuming you had adequate logging
otherwise. And logging an OID just seems too ugly to live.

Another little problem with the quick and dirty solution is that stuff
that's important enough to warrant a log_line_prefix escape is generally
thought to be important enough to warrant inclusion in CSV logs. That
would imply adding a column and taking the resultant compatibility hit.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2011-01-13 01:21:54 Re: Add support for logging the current role
Previous Message Tom Lane 2011-01-13 01:12:03 Re: Fixing GIN for empty/null/full-scan cases