[MDEV-31725] Change visibility of some multi_update members to public Created: 2023-07-17 Updated: 2023-11-28 Resolved: 2023-09-02 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Data Manipulation - Update |
| Fix Version/s: | N/A |
| Type: | Task | Priority: | Critical |
| Reporter: | Gagan Goel (Inactive) | Assignee: | Sergei Golubchik |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
For UPDATEs involving a single table, the server call to handler::ha_direct_update_rows(ha_rows *update_rows, ha_rows *found_rows) allows ColumnStore to correctly set the number of updated rows. However, for UPDATEs involving multi-tables, the server does not call handler::direct_update_rows(). This is causing the following UPDATE statement in ColumnStore to incorrectly report the affected number of rows to the client, even when the actual UPDATE is successful:
As can be seen, the UPDATE is successful but the number of affected rows reported to the client is incorrect. For the above multi-table UPDATE, the server execution calls the below functions in the following order: multi_update::send_eof() is responsible for reporting the count of the affected rows to the client. Knowing this execution order, ColumnStore can correctly set the number of affected rows in handler::rnd_end(), provided the following members of class multi_update are made public: |
| Comments |
| Comment by Gagan Goel (Inactive) [ 2023-07-18 ] |
|
Here is the server-side patch: https://github.com/MariaDB/server/pull/2697 |
| Comment by Sergei Golubchik [ 2023-09-01 ] |
|
where the table is actually updated in the multi-update case? |
| Comment by Sergei Golubchik [ 2023-09-02 ] |
|
answering my question So, this is basically, a hack, columnstore lies to the server that there were no rows affected and the server diligently reports this to the client. I don't think we should extend the server to encourage this kind of hacks and to make them work better. Instead, we should provide a proper multi-update API to the storage engine, so that it wouldn't need to reparse the statement and fake the empty table. Like the direct_update() does in the single-table update case. Meanwhile, columnstore can include server headers after #define private public, this won't need any changes in the server and will be quite in line with the hacks it was doing so far. |
| Comment by Gagan Goel (Inactive) [ 2023-09-05 ] |
|
serg I agree. The proper solution would be to extend the multi-table API and provide a function similar to direct_update() for the singe-table update case. Should I create a new ticket to request this change? On a side note, I was not aware that #define private public was even possible. |