You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[#28956] YSQL: Fix transaction self abort with rollback to savepoint
Summary:
With DDL savepoint support, users can rollback DDL operations as part of rollback to savepoint operations.
When a table is created as part of a savepoint and then the savepoint is rolled back, the table must get deleted. In such scenarios, statements
executed after the rollback to savepoint operation are receiving the transaction expired / conflict error. Example:
```
CREATE TABLE projects (id INT PRIMARY KEY, project_name VARCHAR(100));
INSERT INTO projects (id, project_name) VALUES (101, 'Project Alpha');
-- Conflict
BEGIN ISOLATION LEVEL REPEATABLE READ;
UPDATE projects SET project_name = 'Project Phoenix' WHERE id = 101;
SAVEPOINT sp_mixed;
CREATE TABLE project_logs (log_id INT, entry TEXT);
INSERT INTO project_logs VALUES (1, 'Initial log');
ROLLBACK TO SAVEPOINT sp_mixed;
SELECT project_name FROM projects WHERE id = 101; -- gets expired/conflict error
```
```
ERROR: current transaction is expired or aborted (query layer retry isn't possible because this is not the first command in the transaction. Consider
using READ COMMITTED isolation level.)
```
#### Issue
When the table is deleted, we make DeleteTabletRequestPB request to delete all tablets of the table. As part of the tablet deletion process there is
logic to abort all transactions that are active on the tablet. This leads to the transaction self-abort i.e. the in-flight transaction that initiated
the delete table is also aborted. This leads to future statements within the transaction receiving the transaction expired / conflict error.
#### Why not earlier
This is the first time in YSQL where a tablet deletion is done with an active transaction. Before ddl savepoints, we always deleted tables after the
transaction committed (roll-forward). So the transaction abort during tablet deletion was a no-op.
#### Fix
This revision fixes the issue by not aborting the current transaction if the table is being deleted due to rollback to savepoint operation. We populate the transaction_id in the DeleteTablet request to the tablet server. In the tablet server, we exclude aborting the transaction_id if provided in the request.
**Upgrade/Rollback safety:**
New field is only populated during rollback to savepoint operation which is a new feature and protected under the TEST flag `FLAGS_TEST_ysql_yb_enable_ddl_savepoint_support`.
Jira: DB-18693
Test Plan: ./yb_build.sh --java-test 'org.yb.pgsql.TestDdlSavepoints'
Reviewers: bkolagani, amitanand
Reviewed By: bkolagani
Subscribers: myang, hsunder, svc_phabricator, yql, ybase
Differential Revision: https://phorge.dev.yugabyte.com/D47796
0 commit comments