Observability: pxf_stat_activity and pxf_cancel_backend - #124
Conversation
|
Moved test-related code to separate PR #125 in order to keep PR focused. |
| elog(DEBUG2, "pxf_stat_activity: segment %d requesting %s", | ||
| GpIdentity.segindex, uri.data); | ||
|
|
||
| handle = churl_init_download(uri.data, headers); |
There was a problem hiding this comment.
Shouldn't we check here that there are no curl errors and everything was smoothly inited?
hawq code https://github.com/apache/hawq/blob/master/src/backend/access/external/pxfutils.c#L122C3-L122C57 contains call churl_read_check_connectivity(client_context->handle); I suggest do the similar check
There was a problem hiding this comment.
Good catch, thanks. We do check churl_read_check_connectivity(handle) after consuming the response body, but I agree it is better to keep the same pattern as PxfBridgeImportStart() and validate connectivity immediately after churl_init_download().
24eb226 to
691ac21
Compare
# Conflicts: # .github/workflows/pxf-ci.yml # automation/src/test/java/org/apache/cloudberry/pxf/automation/features/extension/PxfExtensionTest.java # automation/src/test/java/org/apache/cloudberry/pxf/automation/features/extension/PxfFdwExtensionTest.java # ci/docker/pxf-cbdb-dev/common/script/run_tests.sh
691ac21 to
fe63f6b
Compare
|
I have tests this PR in order to detect any password leakage to Also, secret in jdbc URL: with S3: |
Add
pxf_stat_activityAdd
pxf_stat_activityto help DBAs find out what happening inside PXF server.Add
pxf_cancel_backendandpxf_interrupt_backendAdd
pxf_cancel_backendandpxf_interrupt_backendto allow killing running queries.Update tests