Skip site navigation (1) Skip section navigation (2)

Re: logging in high performance systems.

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Theo Schlossnagle <jesus(at)omniti(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: logging in high performance systems.
Date: 2012-01-17 15:12:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Nov 24, 2011 at 04:28, Theo Schlossnagle <jesus(at)omniti(dot)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

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);


In response to


pgsql-hackers by date

Next:From: Matteo BeccatiDate: 2012-01-17 15:33:27
Subject: Re: automating CF submissions (was xlog location arithmetic)
Previous:From: Magnus HaganderDate: 2012-01-17 15:01:23
Subject: psql \timing vs failed statements

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group