Horton

Re: Add support for logging the current role

Josh Berkus <josh@agliodbs.com>

View thread
From: Josh Berkus <josh@agliodbs.com>
To: pgsql-hackers@postgresql.org
Date: 2011-02-17T20:06:34Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add support for an application_name parameter, which is displayed in

  2. Make CSV column ordering a bit more logical.

  3. Extend the format of CSV logs to include the additional information supplied

  4. Add virtual transaction IDs to CSVLOG output, so that messages coming from

  5. Provide for logfiles in machine readable CSV format. In consequence, rename

Robert,

> It seems there's at least one more thing to worry about here, which is
> the overhead of this computation when CSV logging is in use.  If no
> SET ROLE or SET SESSION AUTHORIZATION commands are in use, the code
> will call show_role(), which will return "none".  We'll then strcmp()
> that against "none" and decide to call show_session_authorization(),
> which will call strtoul() to find the comma separator and then return
> a pointer to the string that follows it.  Now, none of that is
> enormously expensive, so maybe it's not worth worrying about, but
> since logging can be a hotspot, I thought I'd mention it and solicit
> an opinion on whether that's likely to be a problem in practice.

That seems like enough to need a performance test.  No clear ideas here
on how we'd measure the overhead of that accurately, though.  Suggestions?

-- 
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com