ADBDEV-5525: Remove per byte precision message truncation for multibyte strings #1185
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
RekGRpth
added a commit
that referenced
this pull request
Jan 20, 2025
…1185) gpdb does not truncate error log correctly on error in external web tables. If error code is not zero and error message is truncated in interpretError on multi-byte character, then assert occurs. If error code is zero and command emit stderr and this error message is truncated in write_log (which is called by read_err_msg) on multi-byte character, then bad character writes to log and later this log can not be correctly read. Solution is to correct error log truncation according to database encoding. (cherry picked from commit ae9e7ac)
RekGRpth
added a commit
that referenced
this pull request
Jan 20, 2025
…1185) gpdb does not truncate error log correctly on error in external web tables. If error code is not zero and error message is truncated in interpretError on multi-byte character, then assert occurs. If error code is zero and command emit stderr and this error message is truncated in write_log (which is called by read_err_msg) on multi-byte character, then bad character writes to log and later this log can not be correctly read. Solution is to correct error log truncation according to database encoding. (cherry picked from commit ae9e7ac)
…1185) gpdb does not truncate error log correctly on error in external web tables. If error code is not zero and error message is truncated in interpretError on multi-byte character, then assert occurs. If error code is zero and command emit stderr and this error message is truncated in write_log (which is called by read_err_msg) on multi-byte character, then bad character writes to log and later this log can not be correctly read. Solution is to correct error log truncation according to database encoding. (cherry picked from commit ae9e7ac) Changes compared to the original commit: 1) added the necessary include 2) added the expected test output for ORCA to a separate file
red1452
approved these changes
Jan 22, 2025
mos65o2
approved these changes
Jan 22, 2025
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.
Remove per byte precision message truncation for multibyte strings (#1185)
gpdb does not truncate error log correctly on error in external web tables.
If error code is not zero and error message is truncated in interpretError
on multi-byte character, then assert occurs.
If error code is zero and command emit stderr and this error message is
truncated in write_log (which is called by read_err_msg) on multi-byte
character, then bad character writes to log and later this log can not be
correctly read.
Solution is to correct error log truncation according to database encoding.
(cherry picked from commit ae9e7ac)
This PR should be rebased to preserve authorship.