Closed whitehawk closed 2 weeks ago
Allure report https://allure.adsw.io/launch/79535
Allure report https://allure.adsw.io/launch/79536
Allure report https://allure.adsw.io/launch/79592
Failed job Regression tests with ORCA on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1874052
Failed job Regression tests with Postgres on x86_64: https://gitlab.adsw.io/arenadata/github_mirroring/gpdb/-/jobs/1874051
bender build
Allure report https://allure.adsw.io/launch/79653
Allure report https://allure.adsw.io/launch/79717
Allure report https://allure.adsw.io/launch/79718
+++DRAFT (for CI only as of yet)+++
Implement MVP to handle command count with exact query (GPDB 6X)
Problem description: Monitoring extension altered 'gp_command_count' value that was dispatched to the segments. It was done to keep tracking of query execution (as 'gp_command_count' was used as 'ccnt' to identify command and track the progress of its execution). It resulted in several issues with IC proxy, shared input scans (and who knows what else...) because of not sync value of 'gp_command_count' between the QD and the QEs.
Solution: Use 'queryCommandId' of 'PGPROC' for command identification.
queryCommandId
is set togp_command_count
every timegp_command_count
is incremented on the dispatcher (that’s old behavior, it is not changed).QueryDesc now contains 1 new field (filled in
CreateQueryDesc()
)command_id
- the updated value ofMyProc->queryCommandId
after its increment.At the Dispatcher side:
Executor switches
MyProc->queryCommandId
tocommand_id
of QueryDesc at the beginning ofExecutorStart()
,ExecutorRun()
,ExecutorFinish()
,ExecutorEnd()
, and back to the preceding value at their end.For utility commands,
increment_command_count()
is added in theProcessUtility()
. At the end ofProcessUtility()
, the value ofMyProc->queryCommandId
is restored to preceding value.That allows to handle cursors and utility commands with plannable parts (like CTAS) without touching the guts of each individual command function (like
ExecCreateTableAs()
).MyProc->queryCommandId
is added to the query message dispatched to the executors (instead ofgp_command_count
).gp_command_count
is not sent to the QEs.At the Executor side backend acquires proper
queryCommandId
from the message dispatched from the query dispatcher. On the QE thegp_command_count
is set to be equal to thequeryCommandId
.Most parts of the code, that used
gp_command_count
, now usequeryCommandId
(some places, that work solely on QD or QE, still usegp_command_count
to reduce delta).