Re: ProcessUtility_hook - Mailing list pgsql-hackers

From Euler Taveira de Oliveira
Subject Re: ProcessUtility_hook
Date
Msg-id 4B04BC12.4010603@timbira.com
Whole thread Raw
In response to Re: ProcessUtility_hook  (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: ProcessUtility_hook
List pgsql-hackers
Itagaki Takahiro escreveu:
> Here is a patch to add ProcessUtility_hook to handle all DDL
> commands in user modules. (ProcessUtility_hook_20091021.patch)
> It adds a global variable 'ProcessUtility_hook' and
> export the original function as 'standard_ProcessUtility'.
> 
I've reviewed your patch. It applies cleanly and compiles without warnings. It
lacks documentation. Could you update it?

The functionality is divided in two parts. The first part is a hook in the
utility module. The idea is capture the commands that doesn't pass through
executor. I'm afraid that that hook will be used only for capturing non-DML
queries. If so, why don't we hack the tcop/postgres.c and grab those queries
from the same point we log statements? This feature is similar to the executor
one. But in the executor case, we use the plan for other things. Other
utilities are (i) using that hook to filter out some non-DML commands and (ii)
developing some non-DML replication mechanism for trigger-based replication
solutions.

The second part is to use that hook to capture non-DML commands for
pg_stat_statements module. Do we need to have rows = 0 for non-DML commands?
Maybe NULL could be an appropriate value. The PREPARE command stopped to countthe number of rows. Should we count the
rowsin EXECUTE command or in the
 
PREPARE command? The other command that doesn't count properly is COPY. Could
you fix that? I'm concerned about storing some commands that expose passwords
like CREATE ROLE foo PASSWORD 'secret'; I know that the queries are only
showed to superusers but maybe we should add this information to documentation
or provide a mechanism to exclude those commands.

I don't know if it is worth the trouble adding some code to capture VACUUM and
ANALYZE commands called inside autovacuum.


--  Euler Taveira de Oliveira http://www.timbira.com/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Listen / Notify - what to do when the queue is full
Next
From: Andrew Chernow
Date:
Subject: Re: Listen / Notify - what to do when the queue is full