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

[YSQL] Avoid rpc from YSQL to local tserver when switching sub transaction #14202

Closed
pkj415 opened this issue Sep 26, 2022 · 0 comments
Closed
Labels
area/ysql Yugabyte SQL (YSQL) kind/bug This issue is a bug priority/medium Medium priority issue status/awaiting-triage Issue awaiting triage

Comments

@pkj415
Copy link
Contributor

pkj415 commented Sep 26, 2022

Jira Link: DB-3666

Description

Currently, YSQL sends the PgSetActiveSubTransactionRequestPB rpc to the local tserver process' Pg client (pg_client_session.cc) when it wants to switch the active sub transaction id. YSQL will switch the active sub transaction id for any of following - user savepoint operations, an internal savepoint created for exception handling or an internal savepoint created before execution of a statement in READ COMMITTED isolation level as explained in 9f2cc7f.

However, a separate rpc is not required. The active sub transaction id can be piggybacked in each PgPerformRequestPB through the PgPerformOptionsPB sub-field and the Pg client session on the tserver can change the active sub transaction id before handling the PgPerformRequestPB.

There are 2 benefits of avoiding the extra PgSetActiveSubTransactionRequestPB rpc -

  1. Improved latency when creating sub transactions for a user savepoint or an exception block in PL/Pgsql procedures/functions.
  2. Lower latency for all statements in READ COMMITTED isolation because there is one less rpc at the start of each statement now for internal sub transaction creation.
@pkj415 pkj415 added area/ysql Yugabyte SQL (YSQL) status/awaiting-triage Issue awaiting triage labels Sep 26, 2022
@yugabyte-ci yugabyte-ci added kind/bug This issue is a bug priority/medium Medium priority issue labels Sep 26, 2022
pkj415 added a commit to pkj415/yugabyte-db that referenced this issue Sep 26, 2022
…ching sub-txns

Currently, YSQL sends the PgSetActiveSubTransactionRequestPB rpc to the local
tserver process' Pg client (pg_client_session.cc) when it wants to switch the
active sub transaction id. YSQL will switch the active sub transaction id for
any of following - user savepoint operations, an internal savepoint created for
exception handling or an internal savepoint created before execution of a
statement in READ COMMITTED isolation level as explained in 9f2cc7f.

However, a separate rpc is not required. The active sub transaction id can be
piggybacked in each PgPerformRequestPB through the PgPerformOptionsPB sub-field
and the Pg client session on the tserver can change the active sub transaction
id before handling the PgPerformRequestPB.

There are 2 benefits of avoiding the extra PgSetActiveSubTransactionRequestPB
rpc -

(1) Improved latency when creating sub transactions for a user savepoint or an
    exception block in PL/Pgsql procedures/functions.
(2) Lower latency for all statements in READ COMMITTED isolation because there
    is one less rpc at the start of each statement now for internal sub
    transaction creation.
pkj415 added a commit that referenced this issue Oct 18, 2022
…b-txns

Summary:
Currently, YSQL sends the PgSetActiveSubTransactionRequestPB rpc to the local
tserver process' Pg client (pg_client_session.cc) when it wants to switch the
active sub transaction id. YSQL will switch the active sub transaction id for
any of following - user savepoint operations, an internal savepoint created for
exception handling or an internal savepoint created before execution of a
statement in READ COMMITTED isolation level as explained in 9f2cc7f.

The PgSetActiveSubTransactionRequestPB rpc was added in c5f5125 as part
of larger PgClient changes. After the change, YSQL sends all rpcs for DMLs to
the PgClientSession on the local tserver process. Distributed transaction
creations and management is handled in the PgClientSession and is not visible
to the YSQL backends. Before this change, YSQL backends managed the lifecycle
of distributed transactions and sub-txn operations were local i.e., any rpcs.

However, a separate rpc is not required for setting the active sub transaction id.
The active sub transaction id can be piggybacked in each PgPerformRequestPB
through the PgPerformOptionsPB sub-field and the Pg client session on the
tserver can change the active sub transaction id before handling the
PgPerformRequestPB.

Removal of this rpc is required as a precursor to solving #12494. As part of #12494,
we can see that postgres allows changing the transaction isolation level after a "BEGIN"
statement. In YSQL, if the "BEGIN" statement starts in READ COMMITTED isolation,
every future statement will acquire an internal savepoint before executing the
statement (refer 9f2cc7f). Without this diff, the internal savepoint creation
results in a PgSetActiveSubTransactionRequestPB rpc which inturn starts a
distributed transaction. This leads to the setting the isolation level in stone,
and not allowing any future modification of the transaction isolation (via the
"SET TRANSACTION ISOLATION LEVEL" statement) even if no other queries have been
executed. It results in the "Attempt to change isolation level of running
transaction..." error message in pg_client_session.cc

NOTE: The RollbackToSubTransaction rpc for rolling back to a sub transaction id stays
and will remain synchronous.

Test Plan: ./yb_build.sh --java-test org.yb.pgsql.TestPgIsolationRegress#isolationRegres

Reviewers: mtakahara, rsami

Reviewed By: mtakahara, rsami

Subscribers: zyu, yql, bogdan

Differential Revision: https://phabricator.dev.yugabyte.com/D19902
@pkj415 pkj415 closed this as completed Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ysql Yugabyte SQL (YSQL) kind/bug This issue is a bug priority/medium Medium priority issue status/awaiting-triage Issue awaiting triage
Projects
None yet
Development

No branches or pull requests

2 participants