mirror of
https://github.com/postgres/postgres.git
synced 2026-10-28 18:24:43 +08:00
Michael Paquier
23bf901fa5
pg_stat_statements decides whether a query is toplevel from the
nesting level at the time each hook runs. A QueryDesc can outlive the
level it started at. For example, a cursor's query starts at level 1,
inside DECLARE, but if the cursor is closed implicitly at COMMIT,
ExecutorEnd runs at level 0. The entry created for the query at parse
analysis has toplevel = false, so ExecutorEnd misses it and stores a
duplicate with the raw query text and toplevel = true.
The same happens with track = top when another extension such as
auto_explain requests query instrumentation. ExecutorEnd stores the
query even though ExecutorStart did not track it.
PGSS is upgraded to save the nesting level in the extension state of the
QueryDesc when ExecutorStart() tracks a query. ExecutorEnd() then uses
it in place of the current level and skips the query if no state was
saved.
For now, only the nesting level is tracked in the private extension
state attached to QueryDesc by PGSS. auto_explain is not touched
either. All these pieces are left as future improvements.
No backpatch is done, due to the ABI changes required in QueryDesc.
This relies on the work done previously in e5d5d1ad1e.
Reported-by: Gaurav Singh <gaurav.singh@yugabyte.com>
Author: Sami Imseih <samimseih@gmail.com>
Author: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/CAEcQ1bZrgwKsauC=03otebkLk77Zc_hYNjhTP3OUdpXs++u+BA@mail.gmail.com
Discussion: https://postgr.es/m/CAA5RZ0v281uwSudcFrY8BymSRDM4J6PAHfzqg_9R+i7zWbTb2A@mail.gmail.com
The PostgreSQL contrib tree
---------------------------
This subtree contains porting tools, analysis utilities, and plug-in
features that are not part of the core PostgreSQL system, mainly
because they address a limited audience or are too experimental to be
part of the main source tree. This does not preclude their
usefulness.
User documentation for each module appears in the main SGML
documentation.
When building from the source distribution, these modules are not
built automatically, unless you build the "world" target. You can
also build and install them all by running "make all" and "make
install" in this directory; or to build and install just one selected
module, do the same in that module's subdirectory.
Some directories supply new user-defined functions, operators, or
types. To make use of one of these modules, after you have installed
the code you need to register the new SQL objects in the database
system by executing a CREATE EXTENSION command. In a fresh database,
you can simply do
CREATE EXTENSION module_name;
See the PostgreSQL documentation for more information about this
procedure.