Skip to content

Bug fix: Call StatementBegin for all TableEditors used in insertIter #2892

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Mar 15, 2025
Merged

Bug fix: Call StatementBegin for all TableEditors used in insertIter #2892

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion sql/rowexec/dml.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,9 +101,15 @@ func (b *BaseBuilder) buildInsertInto(ctx *sql.Context, ii *plan.InsertInto, row
}

if ii.Ignore {
// If ignore is set, then we are either replacing or inserting, but not updating on conflicts
return plan.NewCheckpointingTableEditorIter(insertIter, ed), nil
} else {
return plan.NewTableEditorIter(insertIter, ed), nil
// Otherwise, we are potentially inserting AND updating if there are conflicts
eds := []sql.EditOpenerCloser{ed}
if updater != nil {
eds = append(eds, updater)
}
return plan.NewTableEditorIter(insertIter, eds...), nil
Copy link
Member

@zachmu zachmu Mar 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT we never use more than one editor in practice, despite this constructor accepting multiple editors. I guess if it works and the tests pass it's fine?

But it seems like there should be at least one engine test that doesn't work before this change and passes now.

Copy link
Contributor Author

@fulghum fulghum Mar 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

insertIter takes a replacer, an updater, and an inserter. If the replacer isn't set, it'll use the inserter, and if the inserter fails, it'll handle an ON DUPLICATE UPDATE clause and use the updater.

This doesn't repro with a regular, user table, but is triggered by the docWriter implementation (specifically, the one held in the updater field), because it needs StatementBegin() called to initialize its table writer. Without this, there's a panic from trying to use the nil table writer.

}
}

Expand Down
Loading