Skip to content
  • Dmitry Lenev's avatar
    16761352
    Bug#29903865 "AUTO_INCREMENT_FIELD_NOT_NULL ASSERT FAIL AT TABLE::INIT WHILE SHOW CREATE TABLE". · 16761352
    Dmitry Lenev authored
    
    
    CREATE TABLE ... IGNORE SELECT statement didn't properly cleanup
    TABLE::auto_increment_field_not_null member in cases when last row
    to be inserted was skipped due to failing CHECK constraint.
    As result next statement using the same table might have failed
    on assertion. The problem affected debug builds only.
    
    The problem was caused by missing cleanup of this member in the
    code path that handled CHECK constraint failure in CREATE TABLE
    ... SELECT.
    
    Bug#30126375 "LOAD DATA WITH SET CLAUSE IGNORES NO_AUTO_VALUE_ON_ZERO MODE".
    
    LOAD DATA with SET clause generated new value for auto-increment field
    instead of using 0 value provided in the file even in NO_AUTO_VALUE_ON_ZERO
    mode.
    
    This problem was caused by incorrect handling of auto_increment_field_not_null
    flag as well. Code which processed LOAD DATA's SET clause called fill_record()
    function which wrongly reset this flag, even though it was earlier properly set
    by code loading values from a file. As result 0 coming from the file was
    treated as default, causing new auto-increment generation.
    
    This patch solves these two problems by changing the way fill_record()
    calls handle TABLE::auto_increment_field_not_null flag and how resetting
    of this flag after calls to fill_record() is done.
    
    Specifically:
      - We no longer reset TABLE::auto_increment_field_not_null at the start
        of fill_record(). Instead we rely on the fact that this flag is reset
        for TABLE objects which are new or come from Table Cache. We also
        rely on the fact this flag will be correctly reset before call to
        fill_record() processing next row. This step solves the second bug
        mentioned above.
      - We enforce the latter, and the fact that this flag is correctly
        reset in all cases when we finish row processing by using newly
        introduced RAII class instead of relying on manual cleanup.
        This step solves the first bug mentioned above.
      - Also to avoid  RAII object use in cases when we call fill_record() but
        don't really need value of TABLE::auto_increment_field_not_null (e.g.
        in UPDATE implementation), new argument was added to fill_record()
        to skip raising of this flag.
      - Finally, TABLE::auto_increment_field_not_null flag was renamed to
        better reflect the fact that it actually means that there is explicit
        non-NULL value for the auto-increment field.
    
    Reviewed-by: default avatarSivert Sorumgaard <sivert.sorumgaard@oracle.com>
    16761352
    Bug#29903865 "AUTO_INCREMENT_FIELD_NOT_NULL ASSERT FAIL AT TABLE::INIT WHILE SHOW CREATE TABLE".
    Dmitry Lenev authored
    
    
    CREATE TABLE ... IGNORE SELECT statement didn't properly cleanup
    TABLE::auto_increment_field_not_null member in cases when last row
    to be inserted was skipped due to failing CHECK constraint.
    As result next statement using the same table might have failed
    on assertion. The problem affected debug builds only.
    
    The problem was caused by missing cleanup of this member in the
    code path that handled CHECK constraint failure in CREATE TABLE
    ... SELECT.
    
    Bug#30126375 "LOAD DATA WITH SET CLAUSE IGNORES NO_AUTO_VALUE_ON_ZERO MODE".
    
    LOAD DATA with SET clause generated new value for auto-increment field
    instead of using 0 value provided in the file even in NO_AUTO_VALUE_ON_ZERO
    mode.
    
    This problem was caused by incorrect handling of auto_increment_field_not_null
    flag as well. Code which processed LOAD DATA's SET clause called fill_record()
    function which wrongly reset this flag, even though it was earlier properly set
    by code loading values from a file. As result 0 coming from the file was
    treated as default, causing new auto-increment generation.
    
    This patch solves these two problems by changing the way fill_record()
    calls handle TABLE::auto_increment_field_not_null flag and how resetting
    of this flag after calls to fill_record() is done.
    
    Specifically:
      - We no longer reset TABLE::auto_increment_field_not_null at the start
        of fill_record(). Instead we rely on the fact that this flag is reset
        for TABLE objects which are new or come from Table Cache. We also
        rely on the fact this flag will be correctly reset before call to
        fill_record() processing next row. This step solves the second bug
        mentioned above.
      - We enforce the latter, and the fact that this flag is correctly
        reset in all cases when we finish row processing by using newly
        introduced RAII class instead of relying on manual cleanup.
        This step solves the first bug mentioned above.
      - Also to avoid  RAII object use in cases when we call fill_record() but
        don't really need value of TABLE::auto_increment_field_not_null (e.g.
        in UPDATE implementation), new argument was added to fill_record()
        to skip raising of this flag.
      - Finally, TABLE::auto_increment_field_not_null flag was renamed to
        better reflect the fact that it actually means that there is explicit
        non-NULL value for the auto-increment field.
    
    Reviewed-by: default avatarSivert Sorumgaard <sivert.sorumgaard@oracle.com>
Loading