Re: logging in high performance systems. - Mailing list pgsql-hackers

From Marti Raudsepp
Subject Re: logging in high performance systems.
Date
Msg-id CABRT9RBXfvbf57O53yoxG1eZGXS-xbJ=bTV839-ZvWyw77dvmQ@mail.gmail.com
Whole thread Raw
In response to logging in high performance systems.  (Theo Schlossnagle <jesus@omniti.com>)
Responses Re: logging in high performance systems.  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Thu, Nov 24, 2011 at 04:28, Theo Schlossnagle <jesus@omniti.com> wrote:
> So... here's my first whack at solving this with some flexibility.
>
> The first thing I did was add hook points where immediate statement
> logging happens "pre_exec" and those that present duration
> "post_exec".  These should, with optimization turned on, have only a
> few instructions of impact when no hooks are registered (we could
> hoist the branch outside the function call if that were identified as
> an issue).

Note that the hook mechanism you've built is a departure from how
other hooks are managed in Postgres. Traditionally hooks are just
global function pointers, and each consumer is responsible for storing
the previous value of the hook and chain-calling it in the handler. If
you want to change this pattern, I think you should start another
discussion.

E.g. hook registration looks like:
   next_object_access_hook = object_access_hook;   object_access_hook = sepgsql_object_access;

static void
sepgsql_object_access(ObjectAccessType access, Oid classId, Oid
objectId, int subId)
{   if (next_object_access_hook)       (*next_object_access_hook) (access, classId, objectId, subId);

Regards,
Marti


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: psql \timing vs failed statements
Next
From: Kohei KaiGai
Date:
Subject: Re: [v9.2] sepgsql's DROP Permission checks