After fixing the problem with utility statements, this whole block:
do $$
declare
n integer:= 1;
begin
loop
PERFORM a,b,c,d FROM t1, t2, t3, t4
WHERE t1.a = t2.b AND t3.c = t4.d ORDER BY a;
exit when n = 1000;
n := n + 1;
end loop;
end $$;
Is only processed once, as those are nested statements, in order to
match the 1000 statements the GUC pg_stat_monitor.track must be set to
'all' and then back to the default of 'top' when done testing it.
This commit adds following three sql based testcases:
1) Test unique application name set by user.
2) Histogram function is working properly as desired.
3) Error on insert is shown with proper message.
We are concerned with finished queries in pg_stat_monitor, so state and
state_code columns were removed from the pg_stat_monitor_view as we only
list finished queries on it.
Removed state regression as it is not necessary anymore.
Also, this allowed us to remove the call to pgss_store on ExecutorStart,
which just updated query state to EXEC, thus saving some CPU.
The issue is that between changing GUC "track" from track='top' to
track='all' the queries are executing using previous state of
track='top', to fix that we sleep 1 second after calling
pg_reload_conf() to ensure that queries will run with new settings.
cmd_type: Added missing DROP TABLE t2;
guc: Adjusted to match the updated settings view, which now display
boolean values as 'yes' and 'no', also added the 'options' column
to the output.
guc_1: Handle PostgreSQL versions <= 12 which don't have the
track_planning feature.
rows.out: Added missing DROP TABLE t2. Also removed the line 'ERROR:
relation "t2" already exists' since we fixed the problem in
cmd_type regression.
top_query: Handling both track = 'top' and track = 'all' cases.
top_query_1: On PostgreSQL >= 14 the sub query from the procedure is
stored as (select $1 + $2), whereas on PG <= 13 it is
stored as SELECT (select $1 + $2).
Ibrar Ahmed
Diego Fronza
Naeem Akhter
Naeem Akhter
Mikhail Samoylov