Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Crash in FetchMoreBcpData #1549

Conversation

KushaalShroff
Copy link
Contributor

@KushaalShroff KushaalShroff commented Jun 7, 2023

Description

We are crashing here when the implicit batching of packets is happening at
the very first phase i.e. reading column metadata phase because the table
itself has huge number of columns. Inherently TDS is in a "miscellaneous"
mem context during FETCH phase and the allocated pointer thus seems to crash
for invalid context during pfree.

To fix this we are appending the new packet's data during the FETCH
phase rather than freeing the message data which we do in the PROCESS phase.

Signed-off-by: Kushaal Shroff [email protected]

Issues Resolved

BABEL-4170

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

  • Commits are signed per the DCO using --signoff

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.

We are crashing here when the implicit batching of packets is happening at
the very first phase i.e. reading column metadata phase because the table
itself has huge number of columns. Inherently TDS is in a "miscellaneous"
mem context during FETCH phase and the allocated pointer thus seems to crash
for invalid context during pfree.

To fix this we are appending the new packet's data during the FETCH
phase rather than freeing the message data which we do in the PROCESS phase.
We are crashing here when the implicit batching of packets is happening at
the very first phase i.e. reading column metadata phase because the table
itself has huge number of columns. Inherently TDS is in a "miscellaneous"
mem context during FETCH phase and the allocated pointer thus seems to crash
for invalid context during pfree.

To fix this we are appending the new packet's data during the FETCH
phase rather than freeing the message data which we do in the PROCESS phase.
@KushaalShroff KushaalShroff merged commit d1312f0 into babelfish-for-postgresql:BABEL_3_X_DEV Jun 16, 2023
@KushaalShroff KushaalShroff deleted the babel-jira-4170 branch June 16, 2023 08:17
KushaalShroff added a commit to amazon-aurora/babelfish_extensions that referenced this pull request Jun 16, 2023
We are crashing here when the implicit batching of packets is happening at
the very first phase i.e. reading column metadata phase because the table
itself has huge number of columns. Inherently TDS is in a "miscellaneous"
mem context during FETCH phase and the allocated pointer thus seems to crash
for invalid context during pfree.

To fix this we are appending the new packet's data during the FETCH
phase rather than freeing the message data which we do in the PROCESS phase.

Signed-off-by: Kushaal Shroff <[email protected]>
RIC06X pushed a commit to amazon-aurora/babelfish_extensions that referenced this pull request Jul 6, 2023
We are crashing here when the implicit batching of packets is happening at
the very first phase i.e. reading column metadata phase because the table
itself has huge number of columns. Inherently TDS is in a "miscellaneous"
mem context during FETCH phase and the allocated pointer thus seems to crash
for invalid context during pfree.

To fix this we are appending the new packet's data during the FETCH
phase rather than freeing the message data which we do in the PROCESS phase.

Signed-off-by: Kushaal Shroff <[email protected]>
KushaalShroff added a commit to amazon-aurora/babelfish_extensions that referenced this pull request Jul 18, 2023
We are crashing here when the implicit batching of packets is happening at
the very first phase i.e. reading column metadata phase because the table
itself has huge number of columns. Inherently TDS is in a "miscellaneous"
mem context during FETCH phase and the allocated pointer thus seems to crash
for invalid context during pfree.

To fix this we are appending the new packet's data during the FETCH
phase rather than freeing the message data which we do in the PROCESS phase.

Signed-off-by: Kushaal Shroff <[email protected]>
KushaalShroff added a commit to amazon-aurora/babelfish_extensions that referenced this pull request Jul 18, 2023
We are crashing here when the implicit batching of packets is happening at
the very first phase i.e. reading column metadata phase because the table
itself has huge number of columns. Inherently TDS is in a "miscellaneous"
mem context during FETCH phase and the allocated pointer thus seems to crash
for invalid context during pfree.

To fix this we are appending the new packet's data during the FETCH
phase rather than freeing the message data which we do in the PROCESS phase.

Signed-off-by: Kushaal Shroff <[email protected]>
Santifedz pushed a commit to amazon-aurora/babelfish_extensions that referenced this pull request Aug 7, 2023
We are crashing here when the implicit batching of packets is happening at
the very first phase i.e. reading column metadata phase because the table
itself has huge number of columns. Inherently TDS is in a "miscellaneous"
mem context during FETCH phase and the allocated pointer thus seems to crash
for invalid context during pfree.

To fix this we are appending the new packet's data during the FETCH
phase rather than freeing the message data which we do in the PROCESS phase.

Signed-off-by: Kushaal Shroff <[email protected]>
shardgupta pushed a commit that referenced this pull request Oct 9, 2023
We are crashing here when the implicit batching of packets is happening at
the very first phase i.e. reading column metadata phase because the table
itself has huge number of columns. Inherently TDS is in a "miscellaneous"
mem context during FETCH phase and the allocated pointer thus seems to crash
for invalid context during pfree.

To fix this we are appending the new packet's data during the FETCH
phase rather than freeing the message data which we do in the PROCESS phase.

Issues Resolved
BABEL-4170

Signed-off-by: Kushaal Shroff [email protected]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants