Currently some communication routines between master and segments performing polling of messages from segments rely on InterruptPending flag in detection of cancel or terminating events. This flag is used to define some interruption in CHECK_FOR_INTERRUPTS() routine. Up to some time this flag was closely assigned with some exceptional case, more often with cancel or termination request. But as GPDB merges with newest versions of PostgreSQL, there are more and more cases where interruption begins to denote some not certainly causing error thing, e.g., periodic check of connectivity with client. For this reason it becomes necessary to redefine the usages of InterruptPending flag to no longer erroneously evaluate the set InterruptPending flag as cancel request.
Current patch fixes four places of InterruptPending usage in waiting loops of master-segments communication. Some waiting loops might last a long time and injecting of CHECK_FOR_INTERRUPTS() call to there is necessary to not postpone interruption requests to much. But in other loops the waiting is short enough if connectivity between master and segments is preserved, therefore the check on cancellation or termination in those loops is enough. The case of connection abort or hanging on segments side have to be handled in separate work since it will require to rewrite the logic in waiting loop.
Cherry-pick from greenplum
Currently some communication routines between master and segments performing polling of messages from segments rely on InterruptPending flag in detection of cancel or terminating events. This flag is used to define some interruption in CHECK_FOR_INTERRUPTS() routine. Up to some time this flag was closely assigned with some exceptional case, more often with cancel or termination request. But as GPDB merges with newest versions of PostgreSQL, there are more and more cases where interruption begins to denote some not certainly causing error thing, e.g., periodic check of connectivity with client. For this reason it becomes necessary to redefine the usages of InterruptPending flag to no longer erroneously evaluate the set InterruptPending flag as cancel request.
Current patch fixes four places of InterruptPending usage in waiting loops of master-segments communication. Some waiting loops might last a long time and injecting of CHECK_FOR_INTERRUPTS() call to there is necessary to not postpone interruption requests to much. But in other loops the waiting is short enough if connectivity between master and segments is preserved, therefore the check on cancellation or termination in those loops is enough. The case of connection abort or hanging on segments side have to be handled in separate work since it will require to rewrite the logic in waiting loop.
This PR is the prerequisite for https://github.com/greenplum-db/gpdb/pull/12223
fix #ISSUE_Number
Change logs
Describe your change clearly, including what problem is being solved or what feature is being added.
If it has some breaking backward or forward compatibility, please clary.
Why are the changes needed?
Describe why the changes are necessary.
Does this PR introduce any user-facing change?
If yes, please clarify the previous behavior and the change this PR proposes.
How was this patch tested?
Please detail how the changes were tested, including manual tests and any relevant unit or integration tests.
Contributor's Checklist
Here are some reminders and checklists before/when submitting your pull request, please check them:
make installcheckmake -C src/test installcheck-cbdb-parallelcloudberrydb/devteam for review and approval when your PR is ready🥳