Fix crash in parallel query with enable_pg_hint 'on' 'server' #1690
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kuntalghosh
approved these changes
Aug 8, 2023
forestkeeper
approved these changes
Aug 8, 2023
kuntalghosh
pushed a commit
that referenced
this pull request
Aug 9, 2023
When enable_pg_hint is set to 'on', any query which leads to creation of parallel worker crashes. This is happening because in initialization of parallel worker while restoring the library state of backend to parallel worker, GUC state variable pg_hint_plan.enable_hint is getting set from the assign function of the custom defined variable babelfishpg_tsql.enable_pg_hint, which later in RestoreGUCState function causes an assert failure as it expects all the guc variables of parallel worker to be NULL to begin with, hence crash is happening. This issue is resolved by adding a check in the assign_enable_pg_hint which prevent the parallel worker from setting the GUC variable pg_hint_plan.enable_hint. Task: BABEL-4294 Sign-off-by: Rohit Bhagat <[email protected]>
kuntalghosh
pushed a commit
that referenced
this pull request
Aug 9, 2023
When enable_pg_hint is set to 'on', any query which leads to creation of parallel worker crashes. This is happening because in initialization of parallel worker while restoring the library state of backend to parallel worker, GUC state variable pg_hint_plan.enable_hint is getting set from the assign function of the custom defined variable babelfishpg_tsql.enable_pg_hint, which later in RestoreGUCState function causes an assert failure as it expects all the guc variables of parallel worker to be NULL to begin with, hence crash is happening. This issue is resolved by adding a check in the assign_enable_pg_hint which prevent the parallel worker from setting the GUC variable pg_hint_plan.enable_hint. Task: BABEL-4294 Sign-off-by: Rohit Bhagat <[email protected]>
kuntalghosh
pushed a commit
that referenced
this pull request
Aug 9, 2023
When enable_pg_hint is set to 'on', any query which leads to creation of parallel worker crashes. This is happening because in initialization of parallel worker while restoring the library state of backend to parallel worker, GUC state variable pg_hint_plan.enable_hint is getting set from the assign function of the custom defined variable babelfishpg_tsql.enable_pg_hint, which later in RestoreGUCState function causes an assert failure as it expects all the guc variables of parallel worker to be NULL to begin with, hence crash is happening. This issue is resolved by adding a check in the assign_enable_pg_hint which prevent the parallel worker from setting the GUC variable pg_hint_plan.enable_hint. Task: BABEL-4294 Sign-off-by: Rohit Bhagat <[email protected]>
kuntalghosh
pushed a commit
that referenced
this pull request
Aug 9, 2023
When enable_pg_hint is set to 'on', any query which leads to creation of parallel worker crashes. This is happening because in initialization of parallel worker while restoring the library state of backend to parallel worker, GUC state variable pg_hint_plan.enable_hint is getting set from the assign function of the custom defined variable babelfishpg_tsql.enable_pg_hint, which later in RestoreGUCState function causes an assert failure as it expects all the guc variables of parallel worker to be NULL to begin with, hence crash is happening. This issue is resolved by adding a check in the assign_enable_pg_hint which prevent the parallel worker from setting the GUC variable pg_hint_plan.enable_hint. Task: BABEL-4294 Sign-off-by: Rohit Bhagat <[email protected]>
roshan0708
pushed a commit
to amazon-aurora/babelfish_extensions
that referenced
this pull request
Aug 9, 2023
…ish-for-postgresql#1690) When enable_pg_hint is set to 'on', any query which leads to creation of parallel worker crashes. This is happening because in initialization of parallel worker while restoring the library state of backend to parallel worker, GUC state variable pg_hint_plan.enable_hint is getting set from the assign function of the custom defined variable babelfishpg_tsql.enable_pg_hint, which later in RestoreGUCState function causes an assert failure as it expects all the guc variables of parallel worker to be NULL to begin with, hence crash is happening. This issue is resolved by adding a check in the assign_enable_pg_hint which prevent the parallel worker from setting the GUC variable pg_hint_plan.enable_hint. Task: BABEL-4294 Sign-off-by: Rohit Bhagat <[email protected]>
kuntalghosh
pushed a commit
that referenced
this pull request
Aug 9, 2023
When enable_pg_hint is set to 'on', any query which leads to creation of parallel worker crashes. This is happening because in initialization of parallel worker while restoring the library state of backend to parallel worker, GUC state variable pg_hint_plan.enable_hint is getting set from the assign function of the custom defined variable babelfishpg_tsql.enable_pg_hint, which later in RestoreGUCState function causes an assert failure as it expects all the guc variables of parallel worker to be NULL to begin with, hence crash is happening. This issue is resolved by adding a check in the assign_enable_pg_hint which prevent the parallel worker from setting the GUC variable pg_hint_plan.enable_hint. Task: BABEL-4294 Sign-off-by: Rohit Bhagat <[email protected]>
kuntalghosh
pushed a commit
that referenced
this pull request
Aug 9, 2023
When enable_pg_hint is set to 'on', any query which leads to creation of parallel worker crashes. This is happening because in initialization of parallel worker while restoring the library state of backend to parallel worker, GUC state variable pg_hint_plan.enable_hint is getting set from the assign function of the custom defined variable babelfishpg_tsql.enable_pg_hint, which later in RestoreGUCState function causes an assert failure as it expects all the guc variables of parallel worker to be NULL to begin with, hence crash is happening. This issue is resolved by adding a check in the assign_enable_pg_hint which prevent the parallel worker from setting the GUC variable pg_hint_plan.enable_hint. Task: BABEL-4294 Sign-off-by: Rohit Bhagat <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
When enable_pg_hint is set to 'on', any query which leads to creation of parallel worker crashes. This is happening because in initialization of parallel worker while restoring the library state of backend to parallel worker, GUC state variable pg_hint_plan.enable_hint is getting set from the assign function of the custom defined variable babelfishpg_tsql.enable_pg_hint, which later in RestoreGUCState function causes an assert failure as it expects all the guc variables of parallel worker to be NULL to begin with, hence crash is happening.
This issue is resolved by adding a check in the assign_enable_pg_hint which prevent the parallel worker from setting the GUC variable pg_hint_plan.enable_hint.
Signed-off-by: Rohit Bhagat [email protected]
Issues Resolved
BABEL-4294
Test Scenarios Covered
Use case based -
Added the new test
Boundary conditions -
Arbitrary inputs -
Negative test cases -
Minor version upgrade tests -
Major version upgrade tests -
Performance tests -
Tooling impact -
Client tests -
Check List
By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.