Обсуждение: some log statements ignored

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)


brian

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