Re: Logging (was Re: Suggestion GRANT ALTER, TRIGGER ON ALTER)

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, David Fetter <david(at)fetter(dot)org>
Subject: Re: Logging (was Re: Suggestion GRANT ALTER, TRIGGER ON ALTER)
Date: 2003-06-02 18:51:23
Message-ID: 200306021851.h52IpN609394@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Seems this would be the easiest way:

* Allow logging of only data definition(DDL), or DDL and modification
statements

I can't see why someone would want to see only SELECT and not others,
and I can't imagine wanting modification statements and not DDL.

Added to TODO.

---------------------------------------------------------------------------

Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > Actually, I can see that ... what about an option like "log_statement" which
> > took an array of text which would correspond to the first part of the
> > statement? Then we could leave it up to the DBA do decide what they want to
> > log, with the validation list being the base list of SQL statements, i.e.:
>
> > log_statement = "CREATE TABLE, ALTER TABLE, CREATE VIEW, ALTER VIEW"
>
> Strikes me as a tad unwieldy --- the useful cases would correspond to
> very long log_statement lists, and in every new release the list would
> change. It's probably better to have a very small number of categories,
> something like
> SELECT
> INSERT/UPDATE/DELETE
> all DDL
> and be able to flip logging on/off per category. But we need to think
> about exactly what the categories are.
>
> A related point that I've been meaning to bring up is that I'm not sure
> what sort of logging ought to happen in the new FE/BE protocol's
> PARSE/BIND/EXECUTE universe. Right now, if you've got log_statement on,
> the strings fed to PARSE get logged. But that's got precious little to
> do with what gets executed when, if the client is actually exploiting
> the opportunity to prepare statements in advance of execution. On the
> other hand, I'm not sure we want three log entries for every command.
> Any thoughts on this out there?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-06-02 18:52:22 Re: [GENERAL] ERROR: Memory exhausted in AllocSetAlloc(188)
Previous Message Bruce Momjian 2003-06-02 18:43:32 Re: Feature suggestions (long)