| From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
|---|---|
| To: | pgsql-general(at)postgreSQL(dot)org |
| Subject: | Log_statement behaviour a little misleading? |
| Date: | 2004-01-15 06:55:51 |
| Message-ID: | 40063977.7020106@paradise.net.nz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
This caught me today :
I switched on "log_statement=true" whilst examining a possible foreign
key concurrency problem. I noticed that the generated foreign key check
"SELECT 1 FROM ONLY ... WHERE id = ...FOR UPDATE..."
on the parent table seemed to be only appearing every now and again.
This caused some scratching of the head :-)
Finally light dawned (ok - after reading ri_triggers.c and querying
pg_locks) - that the backend saves the execution plan for the generated
statement, so it is only planned once...and I guess log_statement is
triggered in the plan stage somewhere...
So setting "log_statement=true" does all *statements* - but not all
*executions* of each statement. Is this the intention?
(BTW - I am using 7.4.1)
best wishes
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Travers | 2004-01-15 07:05:17 | Re: what we need to use postgresql in the enterprise |
| Previous Message | Mike Nolan | 2004-01-15 06:55:42 | Re: Schemas not created on restore |