> >> I think the testing discussion should be moved to a different thread.
> >> What do you think?
> > See v4.
> >
> > 0001 deals with reporting queryId in exec_execute_message and
> > exec_bind_message.
> > 0002 deals with reporting queryId after a cache invalidation.
> >
> > There are no tests as this requires more discussion in a separate thread(?)
> At first, these patches look good.
> But I have a feeling of some mess here:
> queryId should be initialised at the top-level query. At the same time,
> the RevalidateCachedQuery routine can change this value in the case of
> the query tree re-validation.
> You can say that this routine can't be called from a non-top-level query
> right now, except SPI. Yes, but what about extensions or future usage?
This is a valid point. RevalidatePlanCache is forcing a
new queryId to be advertised ( 'true' as the second argument to
pgstat_report_query_id) . This means,
v4-0002-Report-new-queryId-after-plancache-re-validation.patch
will result in a non top-level queryId being advertised.
See the attached test case.
I need to think about this a bit.
--
Sami
---------------------------------------------------------------
--- REPRO STEPS
---------------------------------------------------------------
drop table if exists t1 ; create table t1 ( id int );
CREATE OR REPLACE FUNCTION test_prep2() RETURNS void AS $$
DECLARE
lid int;
BEGIN
SELECT * FROM t1 INTO lid;
END;
$$ LANGUAGE plpgsql;
select test_prep();
select test_prep2();
select test_prep2();
select test_prep2();
drop table if exists t1 ; create table t1 ( id int );
select test_prep2();
------------------
--- RESULTS
------------------
The first time "select query, query_id from pg_stat_activity ;" is ran,
we see the correct query_id of the top-level "select test_prep2();"
postgres=# select query, query_id from pg_stat_activity ;
query | query_id
------------------------------------------------+----------------------
select query, query_id from pg_stat_activity ; | 4920466282180912204
select test_prep2(); | -8872343059522300094
|
|
|
|
|
(7 rows)
postgres=# explain verbose select test_prep2();
QUERY PLAN
------------------------------------------
Result (cost=0.00..0.26 rows=1 width=4)
Output: test_prep2()
Query Identifier: -8872343059522300094
(3 rows)
but after the table is dropped and recreated, the advertised
query_id is wrong for the query text. It is the query_id of
"select * from t1;"
postgres=# select query, query_id from pg_stat_activity ;
query | query_id
------------------------------------------------+----------------------
select query, query_id from pg_stat_activity ; | 4920466282180912204
select test_prep2(); | -6535803560158626277
|
|
|
|
|
(7 rows)
postgres=# explain verbose select * from t1;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on public.t1 (cost=0.00..35.50 rows=2550 width=4)
Output: id
Query Identifier: -6535803560158626277
(3 rows)
