brian <[EMAIL PROTECTED]> 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 rel
Tom Lane wrote:
brian <[EMAIL PROTECTED]> 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 IN
brian <[EMAIL PROTECTED]> 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
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
se
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 b
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
