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

[docdb] Support Savepoints with xcluster transactional replication #14308

Closed
shishir2001-yb opened this issue Oct 4, 2022 · 1 comment
Closed
Assignees
Labels
area/docdb YugabyteDB core features kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue xCluster Label for xCluster related issues/improvements

Comments

@shishir2001-yb
Copy link

shishir2001-yb commented Oct 4, 2022

Jira Link: DB-3745

Description

A savepoint is a special mark inside a transaction that allows all commands that are executed after it was established to be rolled back, restoring the transaction state to what it was at the time of the savepoint.

In Yugabyte, Savepoints are implemented using sub-transactions which are either committed or rolled back depending on whether user rollsback or releases savepoint.

As part of transactional xcluster replication, the WAL records from the system.transactions are replicated from the producer to the consumer universe, however the list of aborted/committed sub-transactions is currently not propagated.

To support SAVEPOINTs, changes will be needed to propagate the list of aborted sub-transactions from the Producer->Consumer and propagate that forward to the corresponding transaction coordinator and participants as part of UpdateTransaction.

@shishir2001-yb shishir2001-yb added kind/bug This issue is a bug area/docdb YugabyteDB core features xCluster Label for xCluster related issues/improvements status/awaiting-triage Issue awaiting triage labels Oct 4, 2022
@yugabyte-ci yugabyte-ci added the priority/medium Medium priority issue label Oct 4, 2022
@yugabyte-ci yugabyte-ci removed the status/awaiting-triage Issue awaiting triage label Oct 4, 2022
@yugabyte-ci yugabyte-ci added kind/enhancement This is an enhancement of an existing feature and removed kind/bug This issue is a bug labels Oct 20, 2022
@lingamsandeep lingamsandeep changed the title [X-cluster Replication] X [Savepoints] Data removed by the rollback are being replicated in the target universe [docdb] Support Savepoints with xCluster replication Mar 28, 2023
@lingamsandeep lingamsandeep changed the title [docdb] Support Savepoints with xCluster replication [docdb] Support Savepoints with xCluster transactional replication Mar 28, 2023
@lingamsandeep lingamsandeep changed the title [docdb] Support Savepoints with xCluster transactional replication [docdb] Support Savepoints with xcluster transactional replication Mar 28, 2023
mdbridge added a commit that referenced this issue Apr 5, 2023
…pted when disabled by --enable_pg_savepoint

Summary:
When this flag is set to false, use of SAVEPOINT related features in SQL
produces an error like:
```
2023-03-15 23:47:51.117 UTC [722541] ERROR:  SAVEPOINT <transaction> not supported yet at character 1
2023-03-15 23:47:51.117 UTC [722541] HINT:  See #1125. React with thumbs up to raise its priority
```

This is misleading because it implies the entire feature is not yet
supported whereas it's just unsupported because of gflag setting.

Also, the issue pointed to above (1125) --
#1125 -- seems to be out
of date because it claims that many implemented features are still
unimplemented.

This diff changes the error message to:
```
2023-03-15 23:32:20.676 UTC [680415] ERROR:  SAVEPOINT <transaction> not supported due to setting of flag --enable_pg_savepoints at character 1
```

3/29/2023 UPDATE:
error message is now:
```
ERROR:  SAVEPOINT <transaction> not supported due to setting of flag --enable_pg_savepoints
LINE 1: SAVEPOINT A
        ^
HINT:  flag may have set to false because savepoints do not currently work with xCluster replication (see #14308)
```

Fixes #16374

Test Plan:
```
yb_build.sh --sj  --cxx-test pgwrapper_pg_mini-test --gtest_filter
'*TestSavePointCanBeDisabled*'
```
Look at error message in test log.

3/29/2023 UPDATE:
replace that test with one that checks the error message:
```
yb_build.sh --java-test org.yb.pgsql.TestPgSavepoints
```

Reviewers: slingam, jhe, rsami, hsunder

Reviewed By: hsunder

Subscribers: ybase, rsami

Differential Revision: https://phabricator.dev.yugabyte.com/D23625
premkumr pushed a commit to premkumr/yugabyte-db that referenced this issue Apr 10, 2023
…is attempted when disabled by --enable_pg_savepoint

Summary:
When this flag is set to false, use of SAVEPOINT related features in SQL
produces an error like:
```
2023-03-15 23:47:51.117 UTC [722541] ERROR:  SAVEPOINT <transaction> not supported yet at character 1
2023-03-15 23:47:51.117 UTC [722541] HINT:  See yugabyte#1125. React with thumbs up to raise its priority
```

This is misleading because it implies the entire feature is not yet
supported whereas it's just unsupported because of gflag setting.

Also, the issue pointed to above (1125) --
yugabyte#1125 -- seems to be out
of date because it claims that many implemented features are still
unimplemented.

This diff changes the error message to:
```
2023-03-15 23:32:20.676 UTC [680415] ERROR:  SAVEPOINT <transaction> not supported due to setting of flag --enable_pg_savepoints at character 1
```

3/29/2023 UPDATE:
error message is now:
```
ERROR:  SAVEPOINT <transaction> not supported due to setting of flag --enable_pg_savepoints
LINE 1: SAVEPOINT A
        ^
HINT:  flag may have set to false because savepoints do not currently work with xCluster replication (see yugabyte#14308)
```

Fixes yugabyte#16374

Test Plan:
```
yb_build.sh --sj  --cxx-test pgwrapper_pg_mini-test --gtest_filter
'*TestSavePointCanBeDisabled*'
```
Look at error message in test log.

3/29/2023 UPDATE:
replace that test with one that checks the error message:
```
yb_build.sh --java-test org.yb.pgsql.TestPgSavepoints
```

Reviewers: slingam, jhe, rsami, hsunder

Reviewed By: hsunder

Subscribers: ybase, rsami

Differential Revision: https://phabricator.dev.yugabyte.com/D23625
@mdbridge mdbridge assigned mdbridge and unassigned lingamsandeep Apr 12, 2023
mdbridge added a commit that referenced this issue Apr 22, 2023
…ction info

Summary:
Currently when we use RocksDB logging we get output like:
```
[P-ts-1] I0421 10:09:27.527050 14095 tablet.cc:1490] T 6797611b07a14e0e83d6241d15baf104 P 44f79f51d3f841f1bede12501d097d83: Wrote 5 key/value pairs to kIntents RocksDB:
  ...
  T 6797611b07a14e0e83d6241d15baf104 P 44f79f51d3f841f1bede12501d097d83 [I]: 4. PutCF: SubDocKey(DocKey([], []), []) [kWeakRead, kWeakWrite] HT{ physical: 1682096967524220 w: 1 } => 'xa\xd6\x9f\x11&\x95Ds\x94\x86=\xdd\x1b\x95\x1c?n\x00\x00\x00\x02' (7861D69F112695447394863DDD1B951C3F6E00000002) (error: Corruption (yb/util/slice.cc:137): Wrong first byte, expected 119 but found 110)
```

The corruption error is because the code doesn't understand the subtransaction field.

After the fix in this diff, we get the correct:
```
[P-ts-1] I0421 10:04:30.982218  9659 tablet.cc:1490] T 0a2375b68b264664ba8681b1b9a58c31 P 16429418e9bf4173a80f63b2d15cae67: Wrote 5 key/value pairs to kIntents RocksDB:
  ...
  T 0a2375b68b264664ba8681b1b9a58c31 P 16429418e9bf4173a80f63b2d15cae67 [I]: 4. PutCF: SubDocKey(DocKey([], []), []) [kWeakRead, kWeakWrite] HT{ physical: 1682096670973032 w: 1 } => TransactionId(72a7a781-bb69-4fc6-8e51-d4714db4dce0) SubTransactionId(2) none
```

Test Plan:
```
yb_build.sh   --cxx-test xcluster_ysql-test --gtest_filter '*TransactionWithSavepoints' --test-args '--gtest_also_run_disabled_tests'
```

Reviewers: xCluster, jhe, azhan, sergei, hsunder

Reviewed By: hsunder

Subscribers: ybase

Differential Revision: https://phabricator.dev.yugabyte.com/D24688
mdbridge added a commit that referenced this issue May 4, 2023
…ter replication

Summary:
Added a test per the title.

There are actually two variants of the test because there is an optimization pathway (see the code for tests) that is different enough that I feel that we need a separate test for it being used and a separate one for it not being used.

The new tests are disabled in this diff because the underlying feature they are testing for is currently incompletely implemented, causing them to fail.  The next diff in the stack fixes this and thus un-disables them.
Jira Issue(s): DB-3745

Test Plan:
```
yb_build.sh   --cxx-test xcluster_ysql-test --gtest_filter '*TransactionWithSavepoints*'
```

Reviewers: xCluster, hsunder, rahuldesirazu, jhe

Reviewed By: rahuldesirazu, jhe

Subscribers: rahuldesirazu, jhe, ybase

Differential Revision: https://phabricator.dev.yugabyte.com/D24377
mdbridge added a commit that referenced this issue May 15, 2023
…AVEPOINTs

Summary:
Background:

A savepoint is a special mark inside a transaction that allows all commands that are executed after it was established to be rolled back, restoring the transaction state to what it was at the time of the savepoint.

In Yugabyte, Savepoints are implemented using sub-transactions, which are either committed or rolled back depending on whether user rolls back or releases the savepoint.

Each intent belonging to a transaction is labeled with a subtransaction ID.  As the transaction proceeds, the transaction manager keeps track of which subtransactions have been aborted so far.  This set is incorporated in the COMMITTED Raft record when the transaction is committed.  This information is then used by the apply transaction logic to figure out which intents should actually be applied.

Before this diff, the subtransaction information, both for intents and for what was aborted, was not replicated across to the consumer side or used to do transaction applications.

What this diff does at a high level:
* in the CDC producer:
    * propagates the set of aborted subtransactions as a part of the APPLY CDC record
    * propagates with each intent what subtransaction it belongs to
* on the receiving xCluster side:
    * place the what subtransactions were aborted in the apply external transactions info of the WriteRequestPB
    * likewise, encode the subtransaction ID of each intent
* on the consumer tablet:
    * using the received information, apply only the external intents belonging to subtransactions that have not been aborted
* add a new optional field of the compressed external intents format to store the subtransaction ID:
```
  // External intents are stored in the following format:
  //   key:   kExternalTransactionId, txn_id
  //   value: kUuid involved_tablet [kSubTransactionId subtransaction_ID]
  //          kExternalIntents size(intent1_key), intent1_key, size(intent1_value), intent1_value,
  //          size(intent2_key)...  0
  // where size is encoded as varint.
    * we omit the subtransaction ID here and elsewhere when it is 1, the only subtransaction ID used in normal transactions that do not need multiple subtransactions
```

Notes on the new compressed intent format:
* it supports rolling forward existing databases -- we still accept and use the original format
* it will *not* directly support version downgrades as the old code will not understand the new format
    * intents are transient; likely it would be possible to create a run book to support rolling back
* we use no extra space unless a transaction actually has multiple sub transactions
    * note that transactions using the default Postgres isolation level (READ COMMITTED RSN) will be using subtransactions if statements need to be retried
* currently a fixed four bytes are being used for the subtransaction ID field plus a one byte prefix; probably a variable length encoding could save three bytes here if we thought it was needed

What this diff does not do:
* make SAVEPOINT's work with the pre-Hari scheme xCluster transactional replication

Test Plan:
This diff enables the existing two failing tests for SAVEPOINT with transactional xCluster replication; they are now passing:
```
yb_build.sh --cxx-test xcluster_ysql-test --gtest_filter '*TransactionWithSavepoints*'
```

For better debugging messages right now, turn off packing:
```
yb_build.sh --cxx-test xcluster_ysql-test --gtest_filter '*TransactionWithSavepoints*' --test-args '--ysql_enable_packed_row=false'
```

I think you get the clearest sense of what's going on by looking at the intents of one producer TServer and one consumer TServer.

For the test without optimization (TransactionWithSavepointsNoOpt), the SQL we are running is:
```
  // Create two SAVEPOINTs but abort only one of them; all the writes except the aborted one should
  // be replicated and visible on the consumer side.
  ASSERT_OK(conn.Execute("BEGIN"));
  ASSERT_OK(conn.ExecuteFormat("insert into $0 values(1777777)", table_name));
  ASSERT_OK(conn.Execute("SAVEPOINT a"));
  ASSERT_OK(conn.ExecuteFormat("insert into $0 values(2777777)", table_name));
  ASSERT_OK(conn.Execute("RELEASE SAVEPOINT a"));
  ASSERT_OK(conn.Execute("SAVEPOINT b"));
  ASSERT_OK(conn.ExecuteFormat("insert into $0 values(3777777)", table_name));
  ASSERT_OK(conn.Execute("ROLLBACK TO SAVEPOINT b"));
  ASSERT_OK(conn.ExecuteFormat("insert into $0 values(4777777)", table_name));
  ASSERT_OK(conn.Execute("COMMIT"));
```

That results in the following (omitting uninteresting writes) on the producer tablet:
```
  # intents in the uncompressed format for [1-4]777777, with corresponding subtransaction IDs
  # remember that we omit sub transaction ID 1.
[P-ts-1] I0424 15:10:25.392364  2390 tablet.cc:1502] T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35: Wrote 7 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 1. PutCF: TXN META eed9b150-0180-498c-bee9-eb2072b3f12d => { transaction_id: eed9b150-0180-498c-bee9-eb2072b3f12d isolation: SNAPSHOT_ISOLATION status_tablet: a13645c266084622bfe6e29190338041 priority: 15920732136751982613 start_time: { days: 19471 time: 15:10:25.380609 } locality: GLOBAL old_status_tablet:  external_transaction: 0}
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 2. PutCF: SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.388093 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) WriteId(0) null
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 3. PutCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 } => SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.388093 }
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 4. PutCF: SubDocKey(DocKey(0x56f1, [1777777], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.388093 w: 1 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) none
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 5. PutCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 w: 1 } => SubDocKey(DocKey(0x56f1, [1777777], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.388093 w: 1 }
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 6. PutCF: SubDocKey(DocKey([], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.388093 w: 2 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) none
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 7. PutCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 w: 2 } => SubDocKey(DocKey([], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.388093 w: 2 }
[P-ts-1] I0424 15:10:25.396523  2845 tablet.cc:1502] T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35: Wrote 7 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35 [I]: 2. PutCF: SubDocKey(DocKey(0xdaa5, [2777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.393740 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) SubTransactionId(2) WriteId(0) null
[P-ts-1] I0424 15:10:25.403523  2390 tablet.cc:1502] T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35: Wrote 7 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 2. PutCF: SubDocKey(DocKey(0x2ead, [3777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.399436 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) SubTransactionId(3) WriteId(0) null
[P-ts-1] I0424 15:10:25.418630  2349 tablet.cc:1502] T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35: Wrote 6 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 1. PutCF: SubDocKey(DocKey(0x58db, [4777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.411547 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) SubTransactionId(4) WriteId(1) null

  # start application: we write all of these except 3777777 and delete all the intents
[P-ts-1] I0424 15:10:25.544713  2845 tablet.cc:1502] T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35: Wrote 1 key/value pairs to kRegular RocksDB:
[P-ts-1]:   T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35 [R]: 1. PutCF: SubDocKey(DocKey(0xdaa5, [2777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 }]) => null
[P-ts-1] I0424 15:10:25.544978  2112 tablet.cc:1502] T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35: Wrote 7 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 1. SingleDeleteCF: TXN META eed9b150-0180-498c-bee9-eb2072b3f12d
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 2. SingleDeleteCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.399436 }
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 3. SingleDeleteCF: SubDocKey(DocKey(0x2ead, [3777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.399436 }
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 4. SingleDeleteCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.399436 w: 1 }
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 5. SingleDeleteCF: SubDocKey(DocKey(0x2ead, [3777777], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.399436 w: 1 }
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 6. SingleDeleteCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.399436 w: 2 }
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 7. SingleDeleteCF: SubDocKey(DocKey([], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.399436 w: 2 }
[P-ts-1] I0424 15:10:25.545965  2877 tablet.cc:1502] T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35: Wrote 7 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35 [I]: 3. SingleDeleteCF: SubDocKey(DocKey(0xdaa5, [2777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.393740 }
[P-ts-1] I0424 15:10:25.548563  2390 tablet.cc:1502] T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35: Wrote 2 key/value pairs to kRegular RocksDB:
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [R]: 1. PutCF: SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 }]) => null
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [R]: 2. PutCF: SubDocKey(DocKey(0x58db, [4777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 w: 1 }]) => null
[P-ts-1] I0424 15:10:25.549944  2113 tablet.cc:1502] T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35: Wrote 13 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 3. SingleDeleteCF: SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.388093 }
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 9. SingleDeleteCF: SubDocKey(DocKey(0x58db, [4777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.411547 }
```

What about on a consumer tablet?  We see:
```
  # writing compressed external intents:
[C-ts-1] I0424 15:10:25.426849  2747 tablet.cc:1502] T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800: Wrote 1 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. PutCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.393740 } => IT 77394a9a5e254a619ec409feef132a4a SubTransaction(2) [SubDocKey(DocKey(0xdaa5, [2777777], []), [SystemColumnId(0)]) -> null]
[C-ts-1] I0424 15:10:25.448917  2755 tablet.cc:1502] T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800: Wrote 2 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. PutCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 } => IT 04dc80f0149a43aa80204871d74d693a [SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0)]) -> null]
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [I]: 2. PutCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 w: 1 } => IT 04dc80f0149a43aa80204871d74d693a SubTransaction(4) [SubDocKey(DocKey(0x58db, [4777777], []), [SystemColumnId(0)]) -> null]
[C-ts-1] I0424 15:10:25.471230  2970 tablet.cc:1502] T 02d87d4d5a754daeaa5ad8849c3e15c6 P 5006739d83864a0789b86f3df1a6f800: Wrote 1 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 02d87d4d5a754daeaa5ad8849c3e15c6 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. PutCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.399436 } => IT a380379d15f84ea39791f18cf5c20f3a SubTransaction(3) [SubDocKey(DocKey(0x2ead, [3777777], []), [SystemColumnId(0)]) -> null]

  # write in just the the un-aborted three values
[C-ts-1] I0424 15:10:25.562391  2755 tablet.cc:1502] T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800: Wrote 2 key/value pairs to kRegular RocksDB:
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [R]: 1. PutCF: SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 }]) => null
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [R]: 2. PutCF: SubDocKey(DocKey(0x58db, [4777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 w: 1 }]) => null
[C-ts-1] I0424 15:10:25.646379  2755 tablet.cc:1502] T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800: Wrote 1 key/value pairs to kRegular RocksDB:
[C-ts-1]:   T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800 [R]: 1. PutCF: SubDocKey(DocKey(0xdaa5, [2777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 }]) => null

  # deleting the compressed external intents:
[C-ts-1] I0424 15:10:25.562269  2755 tablet.cc:1502] T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800: Wrote 2 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. SingleDeleteCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 }
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [I]: 2. SingleDeleteCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 w: 1 }
[C-ts-1] I0424 15:10:25.583690  2971 tablet.cc:1502] T 02d87d4d5a754daeaa5ad8849c3e15c6 P 5006739d83864a0789b86f3df1a6f800: Wrote 1 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 02d87d4d5a754daeaa5ad8849c3e15c6 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. SingleDeleteCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.399436 }
[C-ts-1] I0424 15:10:25.646289  2755 tablet.cc:1502] T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800: Wrote 1 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. SingleDeleteCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.393740 }
```

As you can see, the correct three of the four values got written on both sides.

Reviewers: hsunder, slingam, rahuldesirazu, xCluster, rsami

Reviewed By: hsunder, slingam, rsami

Subscribers: slingam, ybase, bogdan

Differential Revision: https://phorge.dev.yugabyte.com/D24763
mdbridge added a commit that referenced this issue May 18, 2023
…ectly handles SAVEPOINTs

Summary:
Original commit: c1ab3e7 / D24763

Changes made while cherry picking the original commit:
    * dropped changes to src/yb/integration-tests/xcluster_ysql-test.cc
        * this was just re-enabling the tests, which don't exist in 2.18
    * rename dockv->docdb because that refactoring was not backported

NOTE: the tests that accompanied the original version of this diff stack are not being back ported as part of this diff.

Background:

A savepoint is a special mark inside a transaction that allows all commands that are executed after it was established to be rolled back, restoring the transaction state to what it was at the time of the savepoint.

In Yugabyte, Savepoints are implemented using sub-transactions, which are either committed or rolled back depending on whether user rolls back or releases the savepoint.

Each intent belonging to a transaction is labeled with a subtransaction ID.  As the transaction proceeds, the transaction manager keeps track of which subtransactions have been aborted so far.  This set is incorporated in the COMMITTED Raft record when the transaction is committed.  This information is then used by the apply transaction logic to figure out which intents should actually be applied.

Before this diff, the subtransaction information, both for intents and for what was aborted, was not replicated across to the consumer side or used to do transaction applications.

What this diff does at a high level:
* in the CDC producer:
    * propagates the set of aborted subtransactions as a part of the APPLY CDC record
    * propagates with each intent what subtransaction it belongs to
* on the receiving xCluster side:
    * place the what subtransactions were aborted in the apply external transactions info of the WriteRequestPB
    * likewise, encode the subtransaction ID of each intent
* on the consumer tablet:
    * using the received information, apply only the external intents belonging to subtransactions that have not been aborted
* add a new optional field of the compressed external intents format to store the subtransaction ID:
```
  // External intents are stored in the following format:
  //   key:   kExternalTransactionId, txn_id
  //   value: kUuid involved_tablet [kSubTransactionId subtransaction_ID]
  //          kExternalIntents size(intent1_key), intent1_key, size(intent1_value), intent1_value,
  //          size(intent2_key)...  0
  // where size is encoded as varint.
    * we omit the subtransaction ID here and elsewhere when it is 1, the only subtransaction ID used in normal transactions that do not need multiple subtransactions
```

Notes on the new compressed intent format:
* it supports rolling forward existing databases -- we still accept and use the original format
* it will *not* directly support version downgrades as the old code will not understand the new format
    * intents are transient; likely it would be possible to create a run book to support rolling back
* we use no extra space unless a transaction actually has multiple sub transactions
    * note that transactions using the default Postgres isolation level (READ COMMITTED RSN) will be using subtransactions if statements need to be retried
* currently a fixed four bytes are being used for the subtransaction ID field plus a one byte prefix; probably a variable length encoding could save three bytes here if we thought it was needed

What this diff does not do:
* make SAVEPOINT's work with the pre-Hari scheme xCluster transactional replication

Test Plan:
(The described tests here
 have not been back ported)
This diff enables the existing two failing tests for SAVEPOINT with transactional xCluster replication; they are now passing:
```
yb_build.sh --cxx-test xcluster_ysql-test --gtest_filter '*TransactionWithSavepoints*'
```

For better debugging messages right now, turn off packing:
```
yb_build.sh --cxx-test xcluster_ysql-test --gtest_filter '*TransactionWithSavepoints*' --test-args '--ysql_enable_packed_row=false'
```

I think you get the clearest sense of what's going on by looking at the intents of one producer TServer and one consumer TServer.

For the test without optimization (TransactionWithSavepointsNoOpt), the SQL we are running is:
```
  // Create two SAVEPOINTs but abort only one of them; all the writes except the aborted one should
  // be replicated and visible on the consumer side.
  ASSERT_OK(conn.Execute("BEGIN"));
  ASSERT_OK(conn.ExecuteFormat("insert into $0 values(1777777)", table_name));
  ASSERT_OK(conn.Execute("SAVEPOINT a"));
  ASSERT_OK(conn.ExecuteFormat("insert into $0 values(2777777)", table_name));
  ASSERT_OK(conn.Execute("RELEASE SAVEPOINT a"));
  ASSERT_OK(conn.Execute("SAVEPOINT b"));
  ASSERT_OK(conn.ExecuteFormat("insert into $0 values(3777777)", table_name));
  ASSERT_OK(conn.Execute("ROLLBACK TO SAVEPOINT b"));
  ASSERT_OK(conn.ExecuteFormat("insert into $0 values(4777777)", table_name));
  ASSERT_OK(conn.Execute("COMMIT"));
```

That results in the following (omitting uninteresting writes) on the producer tablet:
```
  # intents in the uncompressed format for [1-4]777777, with corresponding subtransaction IDs
  # remember that we omit sub transaction ID 1.
[P-ts-1] I0424 15:10:25.392364  2390 tablet.cc:1502] T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35: Wrote 7 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 1. PutCF: TXN META eed9b150-0180-498c-bee9-eb2072b3f12d => { transaction_id: eed9b150-0180-498c-bee9-eb2072b3f12d isolation: SNAPSHOT_ISOLATION status_tablet: a13645c266084622bfe6e29190338041 priority: 15920732136751982613 start_time: { days: 19471 time: 15:10:25.380609 } locality: GLOBAL old_status_tablet:  external_transaction: 0}
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 2. PutCF: SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.388093 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) WriteId(0) null
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 3. PutCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 } => SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.388093 }
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 4. PutCF: SubDocKey(DocKey(0x56f1, [1777777], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.388093 w: 1 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) none
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 5. PutCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 w: 1 } => SubDocKey(DocKey(0x56f1, [1777777], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.388093 w: 1 }
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 6. PutCF: SubDocKey(DocKey([], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.388093 w: 2 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) none
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 7. PutCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 w: 2 } => SubDocKey(DocKey([], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.388093 w: 2 }
[P-ts-1] I0424 15:10:25.396523  2845 tablet.cc:1502] T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35: Wrote 7 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35 [I]: 2. PutCF: SubDocKey(DocKey(0xdaa5, [2777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.393740 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) SubTransactionId(2) WriteId(0) null
[P-ts-1] I0424 15:10:25.403523  2390 tablet.cc:1502] T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35: Wrote 7 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 2. PutCF: SubDocKey(DocKey(0x2ead, [3777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.399436 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) SubTransactionId(3) WriteId(0) null
[P-ts-1] I0424 15:10:25.418630  2349 tablet.cc:1502] T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35: Wrote 6 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 1. PutCF: SubDocKey(DocKey(0x58db, [4777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.411547 } => TransactionId(eed9b150-0180-498c-bee9-eb2072b3f12d) SubTransactionId(4) WriteId(1) null

  # start application: we write all of these except 3777777 and delete all the intents
[P-ts-1] I0424 15:10:25.544713  2845 tablet.cc:1502] T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35: Wrote 1 key/value pairs to kRegular RocksDB:
[P-ts-1]:   T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35 [R]: 1. PutCF: SubDocKey(DocKey(0xdaa5, [2777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 }]) => null
[P-ts-1] I0424 15:10:25.544978  2112 tablet.cc:1502] T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35: Wrote 7 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 1. SingleDeleteCF: TXN META eed9b150-0180-498c-bee9-eb2072b3f12d
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 2. SingleDeleteCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.399436 }
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 3. SingleDeleteCF: SubDocKey(DocKey(0x2ead, [3777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.399436 }
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 4. SingleDeleteCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.399436 w: 1 }
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 5. SingleDeleteCF: SubDocKey(DocKey(0x2ead, [3777777], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.399436 w: 1 }
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 6. SingleDeleteCF: TXN REV eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.399436 w: 2 }
[P-ts-1]:   T a380379d15f84ea39791f18cf5c20f3a P c630698bd61844ed8dd059f9b9b30d35 [I]: 7. SingleDeleteCF: SubDocKey(DocKey([], []), []) [kWeakRead, kWeakWrite] HT{ days: 19471 time: 15:10:25.399436 w: 2 }
[P-ts-1] I0424 15:10:25.545965  2877 tablet.cc:1502] T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35: Wrote 7 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T 77394a9a5e254a619ec409feef132a4a P c630698bd61844ed8dd059f9b9b30d35 [I]: 3. SingleDeleteCF: SubDocKey(DocKey(0xdaa5, [2777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.393740 }
[P-ts-1] I0424 15:10:25.548563  2390 tablet.cc:1502] T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35: Wrote 2 key/value pairs to kRegular RocksDB:
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [R]: 1. PutCF: SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 }]) => null
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [R]: 2. PutCF: SubDocKey(DocKey(0x58db, [4777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 w: 1 }]) => null
[P-ts-1] I0424 15:10:25.549944  2113 tablet.cc:1502] T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35: Wrote 13 key/value pairs to kIntents RocksDB:
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 3. SingleDeleteCF: SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.388093 }
[P-ts-1]:   T 04dc80f0149a43aa80204871d74d693a P c630698bd61844ed8dd059f9b9b30d35 [I]: 9. SingleDeleteCF: SubDocKey(DocKey(0x58db, [4777777], []), [SystemColumnId(0)]) [kStrongRead, kStrongWrite] HT{ days: 19471 time: 15:10:25.411547 }
```

What about on a consumer tablet?  We see:
```
  # writing compressed external intents:
[C-ts-1] I0424 15:10:25.426849  2747 tablet.cc:1502] T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800: Wrote 1 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. PutCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.393740 } => IT 77394a9a5e254a619ec409feef132a4a SubTransaction(2) [SubDocKey(DocKey(0xdaa5, [2777777], []), [SystemColumnId(0)]) -> null]
[C-ts-1] I0424 15:10:25.448917  2755 tablet.cc:1502] T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800: Wrote 2 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. PutCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 } => IT 04dc80f0149a43aa80204871d74d693a [SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0)]) -> null]
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [I]: 2. PutCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 w: 1 } => IT 04dc80f0149a43aa80204871d74d693a SubTransaction(4) [SubDocKey(DocKey(0x58db, [4777777], []), [SystemColumnId(0)]) -> null]
[C-ts-1] I0424 15:10:25.471230  2970 tablet.cc:1502] T 02d87d4d5a754daeaa5ad8849c3e15c6 P 5006739d83864a0789b86f3df1a6f800: Wrote 1 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 02d87d4d5a754daeaa5ad8849c3e15c6 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. PutCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.399436 } => IT a380379d15f84ea39791f18cf5c20f3a SubTransaction(3) [SubDocKey(DocKey(0x2ead, [3777777], []), [SystemColumnId(0)]) -> null]

  # write in just the the un-aborted three values
[C-ts-1] I0424 15:10:25.562391  2755 tablet.cc:1502] T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800: Wrote 2 key/value pairs to kRegular RocksDB:
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [R]: 1. PutCF: SubDocKey(DocKey(0x56f1, [1777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 }]) => null
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [R]: 2. PutCF: SubDocKey(DocKey(0x58db, [4777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 w: 1 }]) => null
[C-ts-1] I0424 15:10:25.646379  2755 tablet.cc:1502] T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800: Wrote 1 key/value pairs to kRegular RocksDB:
[C-ts-1]:   T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800 [R]: 1. PutCF: SubDocKey(DocKey(0xdaa5, [2777777], []), [SystemColumnId(0); HT{ days: 19471 time: 15:10:25.527681 }]) => null

  # deleting the compressed external intents:
[C-ts-1] I0424 15:10:25.562269  2755 tablet.cc:1502] T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800: Wrote 2 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. SingleDeleteCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 }
[C-ts-1]:   T 8db1600d22ee4855a1a024dc6ad59a39 P 5006739d83864a0789b86f3df1a6f800 [I]: 2. SingleDeleteCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.388093 w: 1 }
[C-ts-1] I0424 15:10:25.583690  2971 tablet.cc:1502] T 02d87d4d5a754daeaa5ad8849c3e15c6 P 5006739d83864a0789b86f3df1a6f800: Wrote 1 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 02d87d4d5a754daeaa5ad8849c3e15c6 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. SingleDeleteCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.399436 }
[C-ts-1] I0424 15:10:25.646289  2755 tablet.cc:1502] T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800: Wrote 1 key/value pairs to kIntents RocksDB:
[C-ts-1]:   T 4221f0d394b94c5bbf9bcd4f29d20b35 P 5006739d83864a0789b86f3df1a6f800 [I]: 1. SingleDeleteCF: TXN EXT eed9b150-0180-498c-bee9-eb2072b3f12d HT{ days: 19471 time: 15:10:25.393740 }
```

As you can see, the correct three of the four values got written on both sides.

Reviewers: hsunder, slingam, rahuldesirazu, xCluster

Reviewed By: hsunder

Subscribers: bogdan, ybase, slingam

Differential Revision: https://phorge.dev.yugabyte.com/D25430
@mdbridge
Copy link
Contributor

backported to 2.18.1

mdbridge added a commit that referenced this issue Jul 24, 2023
… XCluster

Summary:
See title.
Also changed this flag stability level from evolving to stable.
Jira: DB-3745

Test Plan:
```
$ yb-master --help|grep -A 1 savepoint
    -enable_pg_savepoints (Set to false to disable savepoints in YugaByte
      PostgreSQL API.) type: bool default: true
```

Reviewers: xCluster, hsunder

Reviewed By: hsunder

Subscribers: yql, ybase

Differential Revision: https://phorge.dev.yugabyte.com/D27199
mdbridge added a commit that referenced this issue Jul 25, 2023
…oints work with XCluster

Summary:
Original commit: b924861 / D27199

Clean merge to origin/2.18.

original summary

See title.
Also changed this flag stability level from evolving to stable.
Jira: DB-3745

Test Plan:
```
$ yb-master --help|grep -A 1 savepoint
    -enable_pg_savepoints (Set to false to disable savepoints in YugaByte
      PostgreSQL API.) type: bool default: true
```

Reviewers: xCluster, hsunder

Reviewed By: hsunder

Subscribers: ybase, yql

Differential Revision: https://phorge.dev.yugabyte.com/D27213
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/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue xCluster Label for xCluster related issues/improvements
Projects
None yet
Development

No branches or pull requests

4 participants