bigreybear opened a new pull request, #9485:
URL: https://github.com/apache/iotdb/pull/9485

   ## Description
   
   (same as https://github.com/apache/iotdb/pull/9484)
   
   In determining the size of the pre-allocated segment for an EntityNode, an 
accurate calculation is performed by examining the children of the EntityNode 
if it has fewer than 20 children. Alternatively, the size is estimated using a 
hard-coded step list based on the cardinality of the EntityNode's children.
   
   During the flushing process of the EntityNode, the segment size is assessed 
prior to the insertion of each child, and the segment is re-allocated or 
extended according to the anticipated size. If the segment is unable to 
accommodate the inserted child even after an extension, an exception will be 
raised, indicating that the record is too large or the extension has failed.
   
   This issue arises in an edge case where the EntityNode has fewer than 20 
children, each with a large size (approximately 1000 bytes in total) when 
calculated for pre-allocation. However, before the EntityNode is flushed, a new 
child with a large name and a small buffer, which includes aliases and other 
schema data but measures under 20 bytes, for instance, is inserted. The segment 
size assessment may be misled, resulting in a minor increment for the segment 
extension, e.g., from 1000 bytes to 1022 bytes, leading to an overflow since 
the segment cannot accommodate the large name.
   
   This hotfix takes into account the length of the name, bytes of the name, 
and the record buffer offset when assessing the expected size of the 
WrappedSegment. This issue will not occur with AliasIndexPage or InternalPage, 
as their lengths will never be assessed multiple times due to their fixed 
length. The root cause of the original issue, as well as potential performance 
improvements, can be attributed to the design of the WrappedSegment increment, 
which is determined by a hard-coded step list as aforementioned.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to