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

geo: Ability to select local vs global txn requirements in the context of geopartitioning #10159

Closed
bmatican opened this issue Oct 1, 2021 · 1 comment
Closed

geo: Ability to select local vs global txn requirements in the context of geopartitioning #10159

bmatican opened this issue Oct 1, 2021 · 1 comment
Assignees
@es1024 @deeps1991
Labels
area/ysql Yugabyte SQL (YSQL)
Projects
YSQL Row Level Geo Partitioning

Comments

@bmatican
Copy link
Contributor

bmatican commented Oct 1, 2021

Context: #9980, #10158

As part of adding geopartitioning to the txn status tables, one requirement we want to uphold is that a transaction that needs to touch global data cannot be executed against a txn status tablet that is geo bound to a single fault domain.

What this translates to is

  • We need a way to mark that a txn is global or local. We can start with a bool session variable for now.
  • If the user starts a local txn, but then proceeds to do writes against global tables, we probably want to add and throw a new type of error.
  • The PG layer needs to flow this local vs global information to the TS layer, at the time of picking the txn id, so we can select an appropriate tablet.

Open questions: For local txns, we also need to decide what the placement rules are:

  • We have 3 levels of placement: cloud/region/zone. Do we agree that the locality should be at the region level?
  • Do we need PG to send any info about the placement it wants, or can we just assume that it has already selected the correct TS and then we can use that TS's placement info?
@bmatican bmatican added the area/ysql Yugabyte SQL (YSQL) label Oct 1, 2021
@bmatican bmatican added this to Backlog in YSQL via automation Oct 1, 2021
@bmatican bmatican added this to To Do in Row Level Geo Partitioning via automation Oct 1, 2021
@es1024 es1024 mentioned this issue Nov 10, 2021
Closed
es1024 added a commit that referenced this issue Nov 16, 2021
@es1024
[#10159] geo: Added global_transaction session variable
17484ff 
Summary:
Added the `global_transaction` session variable, which serves as an override for the
`force_global_transactions` gflag and can be used to force a transaction to use global
transaction status tables rather than existing local transaction status tables.

Depends on D13900.

Test Plan:
Manually tested non-local queries with local transaction status tables created to
verify failure when not set. Modified test cases from D13900 to also test with setting
the variable (`ybd --cxx-test pgwrapper_geo_transactions-test`).

Jenkins: urgent

Reviewers: bogdan, mbautin, dsrinivasan, rthallam, dmitry

Reviewed By: dmitry

Subscribers: ybase

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

es1024 commented Nov 16, 2021

Added with 17484ff.

@es1024 es1024 closed this as completed Nov 16, 2021
YSQL automation moved this from Backlog to Done Nov 16, 2021
Row Level Geo Partitioning automation moved this from To Do to Done Nov 16, 2021
timothy-e added a commit that referenced this issue Dec 28, 2021
@timothy-e
[#10159] ysql: Tablegroup placement
27ce754 
Summary:
Use tablespaces for placement for tables in tablegroups.

* Moved the `IsTablegroupParentTable()` and `IsColocatedParentTable()` checks to TableInfo instead of CatalogManager, so that `TableInfo::UsesTablespacesForPlacement` can use them.
* Added a function `ReadTablespaceInfoFromPgYbTablegroup` that updates the table_to_tablespace map with information for the tablegroup's parent table.

Related remaining work: D14426

Test Plan:
```
ybd --java-test org.yb.pgsql.TestTablespaceProperties
```

Reinitialized DB on `48dc70a0775eed9d598a4c2a6ccd9ef3b965695d~` (the parent of the commit where `pg_yb_tablegroup` was introduced), and then ran ysqlsh with these changes. I can see in the logs that tables in a tablespace are being properly balanced, and we don't run into any issues or log spew when `pg_yb_tablegroup` does not exist.

Reviewers: mpolitov, dsrinivasan, skedia

Reviewed By: skedia

Subscribers: ybase, yql, bogdan, smishra

Differential Revision: https://phabricator.dev.yugabyte.com/D14193
@bmatican bmatican mentioned this issue Feb 12, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@es1024 es1024

@deeps1991 deeps1991

Labels
area/ysql Yugabyte SQL (YSQL)
Projects
Row Level Geo Partitioning
Done
YSQL
  
Done
Milestone
No milestone
Development

No branches or pull requests
3 participants
@bmatican @es1024 @deeps1991