Re: BUG #8289: pg_stat_statements incorrect query text when executing multiple queries in a single PQexec

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: potapov(dot)dmitry(at)gmail(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8289: pg_stat_statements incorrect query text when executing multiple queries in a single PQexec
Date: 2013-07-09 19:20:56
Message-ID: 2128.1373397656@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

potapov(dot)dmitry(at)gmail(dot)com writes:
> The testcase runs five UPDATE commands with two PQexec calls.
> First PQexec call runs: "UPDATE t1 SET a=101 WHERE id=0; UPDATE t1 SET a=102
> WHERE id=1; UPDATE t1 SET a=103 WHERE id=2"
> Second PQexec call runs: "UPDATE t2 SET b=1 where a=0; UPDATE t2 SET a=2
> WHERE b=3"

> I expect pg_stat_statements to contain three records with following query
> texts:
> 1) UPDATE t1 SET a=? WHERE id=?
> 2) UPDATE t2 SET b=? where a=?
> 3) UPDATE t2 SET a=? WHERE b=?

> Instead it contains three records with following query texts:
> 1) "UPDATE t2 SET b=1 where a=0; UPDATE t2 SET a=? WHERE b=?"
> 2) "UPDATE t1 SET a=? WHERE id=?; UPDATE t1 SET a=102 WHERE id=1; UPDATE t1
> SET a=103 WHERE id=2"
> 3) "UPDATE t2 SET b=? where a=?; UPDATE t2 SET a=2 WHERE b=3"

Yeah, that's what's going to happen, because there is no infrastructure
for determining which portion of the source text string belongs to which
query.

I suspect there are some other infelicities in pg_stat_statements'
behavior for multi-query strings, too. At least for now, that
combination is best avoided.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2013-07-09 20:53:57 Re: BUG #8290: broken/unexpected locking behavior
Previous Message Jamey Poirier 2013-07-09 19:06:14 Re: BUG #8290: broken/unexpected locking behavior