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.

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

geo: Check for transactions that must be global before taking transaction from pool #11731

Closed
es1024 opened this issue Mar 11, 2022 · 1 comment
Assignees
Labels
area/docdb YugabyteDB core features kind/bug This issue is a bug priority/medium Medium priority issue

Comments

@es1024
Copy link
Contributor

es1024 commented Mar 11, 2022

Jira Link: [DB-341](https://yugabyte.atlassian.net/browse/DB-341)

Description

We currently take from local vs global transaction pools only based on the session variable. This results in transactions running into an error such as:

message: ERROR:  Illegal state: Nonlocal tablet accessed in local transaction: tablet 9131884ba53b4d3bb01db4fc9cb3cbf1: . Errors from tablet servers: [Illegal state (yb/client/transaction.cc:286): Nonlocal tablet accessed in local transaction: tablet 9131884ba53b4d3bb01db4fc9cb3cbf1]

even when the first write is global. We should identify global transactions before taking a transaction from transaction pools when possible.

Context: #9980 #10158

@es1024 es1024 added the area/docdb YugabyteDB core features label Mar 11, 2022
@es1024 es1024 self-assigned this Mar 11, 2022
@es1024 es1024 added this to To Do in Row Level Geo Partitioning via automation Mar 11, 2022
@omkar-yb omkar-yb added this to Backlog in YBase features Apr 7, 2022
es1024 added a commit that referenced this issue May 13, 2022
…m transaction pool

Summary:
Added passing information about locality of statements from Postgres layer to PGGate, and
modified PgClientSession to use this information to take a transaction from the global transaction
pool instead of the local transaction pool when the first statement of a transaction is not
operating on data from the same region.

Also removed the temporary fix added with D15935 / 4c44705 (#11730).

This also fixes #11947 since the nonlocal error is no longer raised in YSQL upgrade in the first place.

Test Plan:
Updated tests in `GeoTransactionsTest` to do local then global operations instead of just
global (which now always starts as global instead), and added a few new checks for the first
operation global case in `GeoTransactionsTest.TestTransactionTabletSelection`:

`ybd --cxx-test pgwrapper_geo_transactions-test --gtest_filter GeoTransactionsTest.TestTransactionTabletSelection`

Ran test added in D15935 / 4c44705 (#11730) to verify everything
works even with temporary fix removed.

`ybd --java_test 'org.yb.pgsql.TestYsqlUpgrade#migrationInGeoPartitionedSetup'`

Verified #11947 is fixed by running:

`ybd --java-test TestYsqlUpgrade`

Reviewers: alex, dsrinivasan, dmitry

Reviewed By: dmitry

Subscribers: rthallam, bogdan, yql, ybase

Differential Revision: https://phabricator.dev.yugabyte.com/D16200
@es1024
Copy link
Contributor Author

es1024 commented May 13, 2022

Added with b5cf788.

@es1024 es1024 closed this as completed May 13, 2022
YBase features automation moved this from Backlog to Done May 13, 2022
Row Level Geo Partitioning automation moved this from To Do to Done May 13, 2022
@yugabyte-ci yugabyte-ci added kind/bug This issue is a bug priority/medium Medium priority issue labels May 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docdb YugabyteDB core features kind/bug This issue is a bug priority/medium Medium priority issue
Development

No branches or pull requests

2 participants