Skip to content
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

Jump to bottom

[YSQL] Transparently restart first statement in txn when possible #9467

Closed
pkj415 opened this issue Jul 26, 2021 · 0 comments
Closed

[YSQL] Transparently restart first statement in txn when possible #9467

pkj415 opened this issue Jul 26, 2021 · 0 comments
Assignees
@pkj415
Labels
area/ysql Yugabyte SQL (YSQL)

Comments

@pkj415
Copy link
Contributor

pkj415 commented Jul 26, 2021

Currently transparent retries are performed for first statement of an implicit/ explicit txn in two cases -

  1. Read restart error on read-only statement
  2. Conflict error on statement with write operations

We should also handle -

  1. Conflicts on read-only statement (this can occur for a read-only statement in SERIALIZABLE isolation)
  2. Read restart error for statement with write operations
@pkj415 pkj415 self-assigned this Jul 26, 2021
@pkj415 pkj415 added the area/ysql Yugabyte SQL (YSQL) label Jul 26, 2021
@pkj415 pkj415 mentioned this issue Jul 26, 2021
Open
pkj415 added a commit to pkj415/yugabyte-db that referenced this issue Sep 22, 2021
@pkj415
[WIP] [yugabyte#9467] [yugabyte#9467] Increase scope of cases where t…
063b8d1 
…ransparent retries are performed

Summary:
Retries are performed in the following extra cases (ofcourse when no response
data has been sent to external client):
1. kReadRestart error on DMLs.
      In this case, the same txn is re-used. It follows that same path as a
      retry on kReadRestart for SELECT.
2. kConflict error on SELECTs.
      In this case, a different txn is created but with same priority. It
      follows the same path as a retry on kConflict for DMLs.
3. KAborted error on DMLs/SELECTs. Note that a kAborted can only be received
   for a txn T1 if another txn's read/write request finds a conflict and
   aborts T1. (TODO: Confirm this claim)

   If this claim is true, we can retry these same as kConflict errors.

Test Plan:
Jenkins: skip
TBD

Reviewers: alex, dmitry, sergei, mihnea

Subscribers: yql

Differential Revision: https://phabricator.dev.yugabyte.com/D12597
pkj415 added a commit to pkj415/yugabyte-db that referenced this issue Sep 28, 2021
@pkj415
[WIP] [yugabyte#9467] [yugabyte#9467] Increase scope of cases where t…
ce8edc3 
…ransparent retries are performed

Summary:
Retries are performed in the following extra cases (ofcourse when no response
data has been sent to external client):
1. kReadRestart error on DMLs.
      In this case, the same txn is re-used. It follows that same path as a
      retry on kReadRestart for SELECT.
2. kConflict error on SELECTs.
      In this case, a different txn is created but with same priority. It
      follows the same path as a retry on kConflict for DMLs.
3. KAborted error on DMLs/SELECTs. Note that a kAborted can only be received
   for a txn T1 if another txn's read/write request finds a conflict and
   aborts T1. (TODO: Confirm this claim)

   If this claim is true, we can retry these same as kConflict errors.

Test Plan:
Jenkins: skip
TBD

Reviewers: alex, dmitry, sergei, mihnea

Subscribers: yql

Differential Revision: https://phabricator.dev.yugabyte.com/D12597
pkj415 added a commit that referenced this issue Oct 1, 2021
@pkj415
[#9467] [YSQL] Increase scope of cases where transparent retries are …
cee3373 
…performed

Summary:
Retries are performed by the postgres layer in the following extra
cases (of-course when no response data has been sent to external client):

i) **kReadRestart error on DMLs.** - In this case, a new txn is created. It
follows that same path as a retry on kReadRestart for SELECT

ii) **kConflict error on SELECTs.** - In this case, a new txn is created but
with same priority. It follows the same path as a retry on kConflict for DMLs.

There are some fixes that were required -
1. Add PG_TRY/PG_CATCH that was missing in portalcmds.c
2.  Flushing buffered ops are end of PG_TRY() in PortalRun(). Reason added
      as comment inline with code.

Test Plan:
./yb_build.sh --java-test org.yb.pgsql.TestPgReadRestarts#update
./yb_build.sh --java-test org.yb.pgsql.TestPgReadRestarts#delete
./yb_build.sh --java-test org.yb.pgsql.TestPgWriteRestart#testSelectConflictRestart

Reviewers: sergei, smishra, mihnea, alex, dmitry

Reviewed By: alex, dmitry

Subscribers: zyu, yql

Differential Revision: https://phabricator.dev.yugabyte.com/D12597
@pkj415 pkj415 closed this as completed Oct 1, 2021
@mtakahar mtakahar mentioned this issue Dec 1, 2021
Open
@m-iancu m-iancu mentioned this issue Mar 7, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pkj415 pkj415

Labels
area/ysql Yugabyte SQL (YSQL)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@pkj415