Re: ProcessUtility_hook

From: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ProcessUtility_hook
Date: 2009-11-30 07:26:01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Euler Taveira de Oliveira <euler(at)timbira(dot)com> wrote:

> 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?

DDLs can be used from user defined functions. It has the same reason
why we have executor hooks instead of tcop hooks.

> The second part is to use that hook to capture non-DML commands for
> pg_stat_statements module.

- I fixed a bug that it should handle only isTopLevel command.
- A new parameter pg_stat_statements.track_ddl (boolean) is
added to enable or disable the feature.

> Do we need to have rows = 0 for non-DML commands?
> Maybe NULL could be an appropriate value.

Yes, but it requires additional management to handle 0 and NULL
separately. I don't think it is worth doing.

> The PREPARE command stopped to count
> the number of rows. Should we count the rows in EXECUTE command or in the
> PREPARE command?

It requires major rewrites of EXECUTE command to pass the number of
affected rows to caller. I doubt it is worth fixing because almost all
drivers use protocol-level prepared statements instead of PREPARE+EXECUTE.

> The other command that doesn't count properly is COPY. Could
> you fix that?

I added codes for it.

> 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 think there is no additonal problem there because we can see the 'secret'
command using pg_stat_activity even now.

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

I'd like to exclude VACUUM and ANALYZE by autovacuum because
pg_stat_statements should not filled with those commands.

ITAGAKI Takahiro
NTT Open Source Software Center

Attachment Content-Type Size
ProcessUtility_hook_20091130.patch application/octet-stream 11.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message rahimeh khodadadi 2009-11-30 07:29:35 Fwd: psql+krb5
Previous Message Andres Freund 2009-11-30 07:20:46 Re: Application name patch - v4