some log statements ignored

brian wrote:

I changed my postgresql.conf to have:

log_statement = mod

It appears to be working, though not logging *all* INSERTs. For
instance, I have a PHP class that inserts into two tables in a
transaction. The log shows the first, but not the second. Has anyone
seen this behaviour?

test=# show log_statement;
log_statement
---------------
mod
(1 row)

I have no idea why that would happen. If you do 'all' do you see all of
them?

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

brian wrote:

I changed my postgresql.conf to have:

log_statement = mod

It appears to be working, though not logging *all* INSERTs. For
instance, I have a PHP class that inserts into two tables in a
transaction. The log shows the first, but not the second. Has anyone
seen this behaviour?

test=# show log_statement;
log_statement
---------------
mod
(1 row)

I have no idea why that would happen. If you do 'all' do you see all of
them?

Sorry--i hadn't had time to run a test. Setting it to 'all' works fine,
and i think i see the problem: the second INSERT is in a prepared
statement, so it's not being logged.

PREPARE mdb2_statement_pgsql00fb05c2c509aa2608b68bf2b87693a2 AS INSERT
INTO ...

(this is using the PEAR MDB2 package)

So, log_statement= 'mod' won't log a "PREPARE ... AS INSERT", i guess.

b

brian <brian@zijn-digital.com> writes:

Sorry--i hadn't had time to run a test. Setting it to 'all' works fine,
and i think i see the problem: the second INSERT is in a prepared
statement, so it's not being logged.

PREPARE mdb2_statement_pgsql00fb05c2c509aa2608b68bf2b87693a2 AS INSERT
INTO ...

I'm betting that's really a Parse protocol message, not a PREPARE
statement as such (the 8.1 logging code misguidedly tries to obscure the
difference). The logging of the subsequent Bind/Execute messages is
really weak in existing releases :-(. We've fixed it up for 8.2 though.

regards, tom lane

Tom Lane wrote:

brian <brian@zijn-digital.com> writes:

Sorry--i hadn't had time to run a test. Setting it to 'all' works fine,
and i think i see the problem: the second INSERT is in a prepared
statement, so it's not being logged.

PREPARE mdb2_statement_pgsql00fb05c2c509aa2608b68bf2b87693a2 AS INSERT
INTO ...

I'm betting that's really a Parse protocol message, not a PREPARE
statement as such (the 8.1 logging code misguidedly tries to obscure the
difference). The logging of the subsequent Bind/Execute messages is
really weak in existing releases :-(. We've fixed it up for 8.2 though.

You mean, because the PREPARE .. AS INSERT is different from the actual
EXECUTE statement that follows it? And the latter isn't flagged as a
"mod" action?

In any case, i guess it's not really a big deal. It just seemed
mysterious why the second one wasn't showing up.

b

brian <brian@zijn-digital.com> writes:

Tom Lane wrote:

I'm betting that's really a Parse protocol message, not a PREPARE
statement as such (the 8.1 logging code misguidedly tries to obscure the
difference). The logging of the subsequent Bind/Execute messages is
really weak in existing releases :-(. We've fixed it up for 8.2 though.

You mean, because the PREPARE .. AS INSERT is different from the actual
EXECUTE statement that follows it? And the latter isn't flagged as a
"mod" action?

No, if you were using actual SQL PREPARE and EXECUTE statements via
"simple query" protocol, I think they would both get logged (at least
the current 8.1.5 code looks like it will, not so sure about 8.1.0-4).
The problem is that "extended query" protocol is a different code path
that doesn't have the same logging support.

regards, tom lane