database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-10-27 00:12:01 +03:00
Code Activity

Set query ID in parallel workers for vacuum, BRIN and btree

Browse Source 
All these code paths use their own entry point when starting parallel
workers, but failed to set a query ID, even if they set a text query.
Hence, this data would be missed in pg_stat_activity for the worker
processes.  The main entry point for parallel query processing,
ParallelQueryMain(), is already doing that by saving its query ID in a
dummy PlannedStmt, but not the others.  The code is changed so as the
query ID of these queries is set in their shared state, and reported
back once the parallel workers start.

Some tests are added to show how the failures can happen for btree and
BRIN with a parallel build enforced, which are able to trigger a failure
in an assertion added by 24f5205948 in the recovery TAP test
027_stream_regress.pl where pg_stat_statements is always loaded.  In
this case, the executor path was taken because the index expression
needs to be flattened when building its IndexInfo.

Alexander Lakhin has noticed the problem in btree, and I have noticed
that the issue was more spread.  This is arguably a bug, but nobody has
complained about that until now, so no backpatch is done out of caution.
If folks would like to see a backpatch, well, let me know.

Reported-by: Alexander Lakhin
Reviewed-by: Sami Imseih
Discussion: https://postgr.es/m/cf3547c1-498a-6a61-7b01-819f902a251f@gmail.com
This commit is contained in:
Michael Paquier
2024-09-30 08:43:28 +09:00
parent 0d5a3d7574
commit 6fd5071909
7 changed files with 64 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
src/backend/commands/vacuumparallel.c
View File

@@ -57,12 +57,13 @@
typedef struct PVShared
{
/*
* Target table relid and log level (for messages about parallel workers
* launched during VACUUM VERBOSE). These fields are not modified during
* the parallel vacuum.
* Target table relid, log level (for messages about parallel workers
* launched during VACUUM VERBOSE) and query ID. These fields are not
* modified during the parallel vacuum.
*/
Oid relid;
int elevel;
uint64 queryid;
/*
* Fields for both index vacuum and cleanup.
@@ -369,6 +370,7 @@ parallel_vacuum_init(Relation rel, Relation *indrels, int nindexes,
MemSet(shared, 0, est_shared_len);
shared->relid = RelationGetRelid(rel);
shared->elevel = elevel;
shared->queryid = pgstat_get_my_query_id();
shared->maintenance_work_mem_worker =
(nindexes_mwm > 0) ?
maintenance_work_mem / Min(parallel_workers, nindexes_mwm) :
@@ -1014,6 +1016,9 @@ parallel_vacuum_main(dsm_segment *seg, shm_toc *toc)
debug_query_string = sharedquery;
pgstat_report_activity(STATE_RUNNING, debug_query_string);
/* Track query ID */
pgstat_report_query_id(shared->queryid, false);
/*
* Open table. The lock mode is the same as the leader process. It's
* okay because the lock mode does not conflict among the parallel