From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | Euler Taveira de Oliveira <euler(at)timbira(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ProcessUtility_hook |
Date: | 2009-12-01 01:11:35 |
Message-ID: | 200912010111.nB11BZP22794@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I have applied this patch, with only a minor wording improvement:
Specify <literal>on</> to track DDL commands, which excludes <command>SELECT</>,
^^^^^^^^^^^^^^
Thanks.
---------------------------------------------------------------------------
Itagaki Takahiro wrote:
>
> 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.
>
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
[ Attachment, skipping... ]
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-01 01:18:24 | Re: Deleted WAL files held open by backends in Linux |
Previous Message | Tom Lane | 2009-12-01 01:02:10 | Re: Block-level CRC checks |