Fix incorrect deleted row count

[Francisco-Morao]

The deleted row count was incorrect when using the USING clause. The problem was caused by the target_tuple_fetched variable always being set to true, preventing rows_affected_count from updating correctly and skipping the break statement. As a result, es_processed was not incremented as expected.

The fix involves introducing an auxiliary variable (rows_affected_aux) to store the number of rows affected by YBCExecWriteStmt. Then, this value is accumulated into rows_affected_count, ensuring accurate tracking.

Fix #25305

[CLAassistant]

All committers have signed the CLA.

[netlify]

✅ Deploy Preview for infallible-bardeen-164bc9 ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	607c084
🔍 Latest deploy log	https://app.netlify.com/sites/infallible-bardeen-164bc9/deploys/67e1e12dd0206f000870b5eb
😎 Deploy Preview	https://deploy-preview-26524--infallible-bardeen-164bc9.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[karthik-ramanathan-3006]

@Francisco-Morao - Thank you for contributing to the yugabyte-db repository!

UPDATE statements with a FROM clause also suffer from the same problem - returning inflated counts when a JOIN producing duplicate rows is used to feed the Update/Delete node.

Ideally, we'd like to use the same fix in both cases. Could you please try your fix with UPDATEs?
I suspect that this might not work as rows_affected_count would no longer return 0 for the duplicate row.

[Francisco-Morao]

@Francisco-Morao - Thank you for contributing to the yugabyte-db repository!

UPDATE statements with a FROM clause also suffer from the same problem - returning inflated counts when a JOIN producing duplicate rows is used to feed the Update/Delete node.

Ideally, we'd like to use the same fix in both cases. Could you please try your fix with UPDATEs? I suspect that this might not work as rows_affected_count would no longer return 0 for the duplicate row.

I just tried to make the change, but it did not work. The problem is most likely in YBCExecuteUpdate, as row_found always returns 1 so true regardless of the conditions. Investigating and solving this bug would require more time. Maybe we should open a new issue for this if one does not already exist.