Adds 2PC distributed commands from other databases #7203

halilozanakgul · 2023-09-14T13:38:45Z

DESCRIPTION: Adds support for 2PC from non-Citus main databases

This PR only adds support for CREATE USER queries, other queries need to be added. But it should be simple because this PR creates the underlying structure.

Citus main database is the database where the Citus extension is created. A non-main database is all the other databases that are in the same node with a Citus main database.

When a CREATE USER query is run on a non-main database we:

Run start_management_transaction on the main database. This function saves the outer transaction's xid (the non-main database query's transaction id) and marks the current query as main db command.
Run execute_command_on_remote_nodes_as_user("CREATE USER <username>", <username to run the command>) on the main database. This function creates the users in the rest of the cluster by running the query on the other nodes. The user on the current node is created by the query on the outer, non-main db, query to make sure consequent commands in the same transaction can see this user.
Run mark_object_distributed on the main database. This function adds the user to pg_dist_object in all of the nodes, including the current one.

This PR also implements transaction recovery for the queries from non-main databases.

src/backend/distributed/commands/extension.c

src/backend/distributed/transaction/remote_transaction.c

src/backend/distributed/transaction/transaction_management.c

marcoslot · 2023-10-11T17:34:54Z

src/backend/distributed/metadata/metadata_cache.c

@@ -5723,6 +5724,10 @@ GetPoolinfoViaCatalog(int32 nodeId)
 char *
 GetAuthinfoViaCatalog(const char *roleName, int64 nodeId)
 {
+	if (!isCitusManagementDatabase())
+	{
+		return "";


Could use a comment

This still applies

src/backend/distributed/transaction/remote_transaction.c

src/backend/distributed/transaction/transaction_management.c

marcoslot · 2023-10-11T17:41:13Z

src/backend/distributed/transaction/remote_transaction.c

+bool IsManagementCommand = false;
+FullTransactionId outerXid;
+static MultiConnection *managementCon = NULL;
+bool CitusManagementDatabase = true;


Do we need this boolean? Seems cheap enough to just check the database name in IsCitusManagementDatabase

I cannot use CurrentDatabaseName() function in the post commit hook, where I need the IsCitusMainDb() check. Because it needs to be in a transaction to be able to access the database names.

One way to check if the database you are connected is the MainDb or not would be to add the following change:

diff --git a/src/backend/distributed/shared_library_init.c b/src/backend/distributed/shared_library_init.c
index 5b0208eca..bbf0d2bc7 100644
--- a/src/backend/distributed/shared_library_init.c
+++ b/src/backend/distributed/shared_library_init.c
@@ -3139,6 +3139,11 @@ CitusAuthHook(Port *port, int status)
InitializeBackendData(port->application_name);

+ bool isInMainDB = strcmp(port->database_name, MainDb) == 0;
/* let other authentication hooks to kick in first */
if (original_client_auth_hook)
{

Note that:

Need to make isInMainDB global

CitusAuthHook is run for all client connections. But it is not run for the background workers (such as autovacuum launcher, Citus maintenance deamon). So you need to initialize isInMainDB with a default value such as isInMainDB = false;

CoordinatedTransactionCallback will be called in those background workers as well. There will be a maintenance deamon connected to MainDb. If we need to do 2PC in there, we should set isMainDB to true there.

src/backend/distributed/metadata/metadata_sync.c

src/backend/distributed/sql/udfs/commit_management_command_2PC/12.1-1.sql

src/backend/distributed/metadata/distobject.c

onurctirtir · 2023-10-12T13:35:01Z

src/backend/distributed/metadata/metadata_sync.c

+		if (IsManagementCommand)
+		{
+			names = namesArg;
+			objectType = "role";


To be on the safe side (and to make this function useful for further cases other than CREATE ROLE), should we use objectType = getObjectTypeDescription(address, false); here too?

(e.g., we will probably use this for CREATE DATABASE as well)

(e.g., we will probably use this for CREATE DATABASE as well)

(Maybe not for CREATE DATABASE because we may want to directly propagate CREATE DATABASE to all nodes as it cannot be executed in a xact block anyway.)

src/backend/distributed/transaction/transaction_management.c

JelteF

Overall this looks like a good approach. I left some comments to improve this.

src/backend/distributed/connection/connection_configuration.c

src/backend/distributed/metadata/distobject.c

src/backend/distributed/metadata/metadata_cache.c

src/backend/distributed/metadata/metadata_sync.c

src/backend/distributed/sql/udfs/commit_management_command_2PC/latest.sql

src/backend/distributed/transaction/remote_transaction.c

src/backend/distributed/sql/udfs/citus_mark_object_distributed/latest.sql

src/backend/distributed/commands/utility_hook.c

src/test/regress/sql/other_databases.sql

src/backend/distributed/commands/utility_hook.c

src/backend/distributed/connection/connection_configuration.c

src/backend/distributed/shared_library_init.c

onurctirtir · 2023-10-30T07:59:11Z

src/backend/distributed/transaction/remote_transaction.c

+PG_FUNCTION_INFO_V1(citus_internal_start_management_transaction);
+PG_FUNCTION_INFO_V1(execute_command_on_other_nodes);
+PG_FUNCTION_INFO_V1(citus_mark_object_distributed);
+PG_FUNCTION_INFO_V1(commit_management_command_2PC);


Should all those functions start with citus_internal?

Also, should they perform our usual checks for citus_internal UDFs?

CheckCitusVersion(ERROR); // also some null input checks go here, via PG_ENSURE_ARGNOTNULL() if (!ShouldSkipMetadataChecks()) { EnsureCoordinatorInitiatedOperation(); }

onurctirtir · 2023-10-30T08:19:38Z

src/backend/distributed/transaction/transaction_management.c

 			{
 				/* handles both already prepared and open transactions */
 				CoordinatedRemoteTransactionsCommit();
 			}

+			if (!IsCitusMainDB())


I'm still concerned about executing below UDF even for regular Citus clusters, due to the check (if !IsCitusMainDb()) not knowing about whether this database is used for db sharding or row-based sharding. Should we check for IsCitusInstalled() too? Or am I missing something?

I think if we're in a sharded not-main database the ideal behaviour would be to create the roles via the current database but add the pg_dist_object records via the main database. (Both as part of the same 2PC)

Until we implement that, we should make sure we keep whatever the current behaviour is in the not-main Citus databases.

IsCitusInstalled()

Can use CitusHasBeenLoaded probably

create the roles via the current database but add the pg_dist_object records via the main database

I'm adding this, and main database also runs the query on the workers too.

I assumed we'll set up the parameters so that IsCitusMainDB will return true for regular Citus database too. Maybe we can rename this, so it'll make more sense?

But sure, I can even add CitusHasBeenLoaded to IsCitusMainDB function.

src/backend/distributed/transaction/transaction_management.c

src/backend/distributed/transaction/worker_transaction.c

onurctirtir · 2023-10-30T08:26:41Z

src/include/distributed/worker_transaction.h

+	/*
+	 * All the active primary nodes in the metadata except the current node
+	 */
+	OTHER_NODES


Suggested change

/*

* All the active primary nodes in the metadata except the current node

*/

OTHER_NODES

/*

* All the active primary nodes in the metadata except the local node

*/

OTHER_NODES

We can discuss but to me the word local means something in this node. So local node doesn't sound right.

I don't think this needs to be introduced anymore. We already have REMOTE_NODES which is the same afaict. It was introduced by @onurctirtir in #7278. Let's also make all other places where we use the term "other nodes" to saying "remote nodes". e.g. the execute_command_on_other_nodes UDF.

src/backend/distributed/transaction/transaction_recovery.c

codecov · 2023-11-17T12:30:46Z

Codecov Report

Merging #7203 (06c2a66) into main (6801a1e) will increase coverage by 0.03%.
The diff coverage is 97.58%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7203      +/-   ##
==========================================
+ Coverage   89.57%   89.61%   +0.03%     
==========================================
  Files         278      278              
  Lines       59984    60100     +116     
  Branches     7469     7487      +18     
==========================================
+ Hits        53732    53857     +125     
+ Misses       4105     4098       -7     
+ Partials     2147     2145       -2

src/backend/distributed/shared_library_init.c

src/backend/distributed/metadata/distobject.c

src/backend/distributed/transaction/remote_transaction.c

JelteF · 2023-12-13T16:34:17Z

src/backend/distributed/transaction/transaction_recovery.c

+			{
+				/*
+				 * The transaction is initiated from an outer transaction and the outer
+				 * transaction is not yet committed, so we should not commit either.
+				 * We remove this transaction from the pendingTransactionSet so it'll
+				 * not be aborted by the loop below.
+				 */
+				hash_search(pendingTransactionSet, transactionName, HASH_REMOVE,
+							&foundPreparedTransactionBeforeCommit);
+				continue;
+			}
+			else if (!outerXactIsInProgress && !outerXactDidCommit)
+			{
+				/*
+				 * Since outer transaction isn't in progress and did not commit we need to
+				 * abort the prepared transaction too. We do this by simply doing the same
+				 * thing we would  do for transactions that are initiated from the main
+				 * database.
+				 */
+				continue;


These two cases are currently not covered by tests yet. But it is important that they do the correct thing. They are hard to test though, because they are about edge cases that can happen after the main database transaction has already successfully committed:

the main db transaction is committed, but the outer has not committed yet

the main db transaction is committed, but the outer transaction failed to commit

I think the easiest way to trigger these cases is by simulating them using the python test framework:

open two connections

in connection A we open a transaction and get its transaction id (transaction A)

in connection B we manually do the flow with all our new functions using the transaction id of transaction A: start_managament_command->mark_object_distributed->execute_command_on_other_nodes->COMMIT

And then for edge case 2 we abort transaction A (and for edge case 1 we do nothing)

we run recover_prepared_transactions

check if the changes made by connection B have been applied or not.

For some explanation of the python test suite you can take a look here:

README: https://github.com/citusdata/citus/blob/main/src/test/regress/citus_tests/test/README.md

Example written by Emel: https://github.com/citusdata/citus/blob/main/src/test/regress/citus_tests/test/test_extension.py

src/backend/distributed/transaction/remote_transaction.c

JelteF · 2023-12-18T09:39:52Z

src/backend/distributed/transaction/remote_transaction.c

+MultiConnection *MainDBConnection = NULL;
+bool IsMainDBCommand = false;
+FullTransactionId OuterXid;
+bool IsMainDB = true;


There should be a code comment saying why we need this boolean (i.e. it makes sense to me after reading the discussion on the PR, but we should have the conclusion as a code comment). Also @emelsimsek said it does not get set automatically for background workers. So we should mention that and probably set it ourselves for the workers that we spawn:

CitusAuthHook is run for all client connections. But it is not run for the background workers (such as autovacuum launcher, Citus maintenance deamon). So you need to initialize isInMainDB with a default value such as isInMainDB = false;

CoordinatedTransactionCallback will be called in those background workers as well. There will be a maintenance deamon connected to MainDb. If we need to do 2PC in there, we should set isMainDB to true there.

The default value is true, and when it is true we don't do any new logic. So, I think the default value should be fine for the background workers too. Do you think we should set it to false there?

Good question. I think false might be better. That way if a background worker does some global DDL (very unlikely) it will always use the "connect to main database" logic. The only downside of that that I can think of would be an unnecessary connection, in the case where the background worker is actually running in the main database.

While if the default is true, that means it will always be executed in the local database. Which would mean that if the background worker runs global DDL (again, very unlikely) while running in a non-main database then that DDL would not be propagated to other nodes.

So I think defaulting to false would be best. Or well, the best would be if would obviously be to automatically detect in background workers in what database we are. But I don't think that's worth the effort at the moment.

IMPORTANT NOTE: The reasoning above applies only when citus.main_db is actually set to something else than the empty string. If citus.main_db is not configured, I think the safest would be to keep IsMainDB default to true. The easiest way for that would be to set it to true/false from _PG_init based on the value of MainDb. Let's do that in this PR.

Finally, I do think that we should add a code comment that we made this decision to not worry about it for now and why:

When citus.main_db is set IsMainDB variable is only ever set to true for connection backends, not background workers. Background worker processes will always report false here, even if they are running in a different database than the citus.main_db. This is currently fine in practice since this we only use this variable when propagating global DDL, which already seems very unlikely to happen from a background worker. And even if it did the only downside of it being true incorrectly when the background worker is running in the citus main database is that the background worker will create an unnecessary connection to the main database.

JelteF · 2023-12-18T09:42:23Z

src/backend/distributed/transaction/remote_transaction.c

+ * IsCitusMainDB returns true if this is the Citus main database.
+ */
+bool
+IsCitusMainDB(void)


I don't think this function has a reason to exist anymore. We can use IsMainDB directly everywhere we use this function.

JelteF · 2023-12-18T09:49:09Z

src/backend/distributed/metadata/distobject.c

+{
+	if (!CitusHasBeenLoaded())
+	{
+		return;


Quoting @onurctirtir from a previous comment that got outdated:

Should we instead throw an error if we don't expect this function to be called when isCitusManagementDatabase() holds?

src/backend/distributed/metadata/distobject.c

JelteF · 2023-12-21T17:21:56Z

src/backend/distributed/connection/connection_configuration.c

@@ -444,7 +444,17 @@ GetEffectiveConnKey(ConnectionHashKey *key)
 		return key;
 	}

+	if (!CitusHasBeenLoaded())


The comment of this function is now even more outdated than it already was. Let's remove the "task tracker" mention from the function comment and replace it with something about the Citus non-main database.

JelteF · 2023-12-21T17:44:28Z

src/backend/distributed/transaction/remote_transaction.c

+	{
+		if (strlen(SuperuserRole) == 0)
+		{
+			ereport(ERROR, (errmsg("No superuser role is given for Citus main "


This is reported as not covered by codecov. I think we should be able to easily cover this case.

JelteF · 2023-12-21T17:46:27Z

src/backend/distributed/metadata/metadata_cache.c

@@ -5722,6 +5723,10 @@ GetPoolinfoViaCatalog(int32 nodeId)
 char *
 GetAuthinfoViaCatalog(const char *roleName, int64 nodeId)
 {
+	if (!CitusHasBeenLoaded())


Could still use a comment, e.g.

This happens when doing global DDL from a Citus non-main database.

JelteF · 2023-12-21T17:50:44Z

src/backend/distributed/sql/citus--12.0-1--12.1-1.sql

+#include "udfs/start_management_transaction/12.1-1.sql"
+#include "udfs/execute_command_on_remote_nodes_as_user/12.1-1.sql"
+#include "udfs/mark_object_distributed/12.1-1.sql"
+#include "udfs/commit_management_command_2pc/12.1-1.sql"
+
+ALTER TABLE pg_catalog.pg_dist_transaction ADD COLUMN outer_xid xid8;


Citus 12.1 has already been released. These should not be included in this file but in the one for citus 12.2: src/backend/distributed/sql/citus--12.1-1--12.2-1.sql

Same for all the included migration files and the downgrade script, they are currently using files with wrong version numbers.

JelteF · 2023-12-21T17:53:46Z

src/test/regress/expected/other_databases.out

@@ -0,0 +1,88 @@
+CREATE SCHEMA other_databases;


As discussed over chat. We should add mx tests for this, i.e. CREATE/DROP USER should work from non citus main databases on workers too.

JelteF · 2023-12-21T17:57:25Z

src/test/regress/citus_tests/test/test_other_databases.py

+    with c.cur(dbname="db1") as cur1:
+        with c.cur() as cur2:


nit: you can combine these two in one with statements, which reduces the indentation of the following code:

Suggested change

with c.cur(dbname="db1") as cur1:

with c.cur() as cur2:

with c.cur(dbname="db1") as cur1, \

c.cur() as cur2:

P.S. I learned of this only a few months ago

JelteF · 2023-12-21T18:09:16Z

src/test/regress/citus_tests/test/test_other_databases.py

+            cur2.execute(
+                "SELECT citus_internal.start_management_transaction('"
+                + str(txid[0][0])
+                + "')"


This is both easier to read (imho) and better practice, because it avoids sql injection (not that that really matters here, but good practice in general not to interpolate sql strings manually when not needed).

Suggested change

cur2.execute(

"SELECT citus_internal.start_management_transaction('"

+ str(txid[0][0])

+ "')"

cur2.execute(

"SELECT citus_internal.start_management_transaction(%s)",

str(txid[0][0]))

JelteF · 2023-12-21T18:20:37Z

src/test/regress/citus_tests/test/test_other_databases.py

+                "SELECT citus_internal.execute_command_on_remote_nodes_as_user('CREATE USER u1;', 'postgres')"
+            )
+            cur2.execute(
+                "SELECT citus_internal.mark_object_distributed(1260, 'u1', 123123)"


Is this actually removed from pg_dist_object on the coordinator now? As far as I can tell this leaks outside of the test.

Maybe easiest solution is just to not call mark_object_distributed. Let's manually remove it at the end of the test.

JelteF · 2023-12-21T18:21:45Z

src/test/regress/citus_tests/test/test_other_databases.py

+                "SELECT citus_internal.execute_command_on_remote_nodes_as_user('CREATE USER u1;', 'postgres')"
+            )
+            cur2.execute(
+                "SELECT citus_internal.mark_object_distributed(1260, 'u1', 123123)"


We should check that this is not visible on the coordinator yet until the commit actually happened. So similar logic like you have now for checking if roles exist.

JelteF · 2023-12-22T08:03:55Z

src/test/regress/citus_tests/test/test_other_databases.py

+            before_commit = c.sql_value(
+                """
+                SELECT result
+                FROM run_command_on_workers($$
+                    SELECT count(*) FROM pg_roles
+                    WHERE rolname = 'u1'
+                $$) LIMIT 1
+                """
+            )


nit: if you're doing the limit one to only check a single worker anyway, I think it's easier to simply connect straight to the worker.

Suggested change

before_commit = c.sql_value(

"""

SELECT result

FROM run_command_on_workers($$

SELECT count(*) FROM pg_roles

WHERE rolname = 'u1'

$$) LIMIT 1

"""

)

before_commit = cluster.workers[0].sql_value(

"SELECT count(*) FROM pg_roles WHERE rolname = 'u1'"

)

JelteF · 2023-12-22T14:44:12Z

src/test/regress/citus_tests/test/test_other_databases.py

+        pdo_before_commit = w0.sql_value(
+            "SELECT count(*) FROM pg_dist_object WHERE objid::regrole::text = 'u1'"
+        )
+
+        assert int(pdo_before_commit) == 0, "role is created despite not committing"


we should also check pg_dist_object on the coordinator, because mark_object_distributed should have effect there too (as opposed to execute_command_on_remote_nodes_as_user). So just copy paste these lines and replace w0 with c, same for other places where we check pg_dist_object in this test file:

Suggested change

pdo_before_commit = w0.sql_value(

"SELECT count(*) FROM pg_dist_object WHERE objid::regrole::text = 'u1'"

)

assert int(pdo_before_commit) == 0, "role is created despite not committing"

pdo_before_commit = c.sql_value(

"SELECT count(*) FROM pg_dist_object WHERE objid::regrole::text = 'u1'"

)

assert int(pdo_before_commit) == 0, "role is created despite not committing"

JelteF

Left one final comment about also testing pg_dist_object on the coordinator. Once you do that and get tests to pass in CI we can merge this.

I noticed while reviewing #7203 that there as no example of executing sql on a worker for the pytest README. Since this is a pretty common thing that people want to do, this PR adds that.

ivyazmitinov · 2024-05-09T14:40:18Z

src/backend/distributed/transaction/transaction_management.c

+			 */
+			if (!IsMainDB && MainDBConnection != NULL)
+			{
+				RunCitusMainDBQuery(COMMIT_MANAGEMENT_COMMAND_2PC);


Invoking citus_internal.commit_management_command_2pc() here, in the XACT_EVENT_COMMIT handler makes the server much more susceptible to crashes, because every error thrown here will lead to a process termination. I faced it when introducing a timeout for maintenance connection pool in #7286.
It would be better to signal the maintenance worker to trigger a recovery somehow...
cc @JelteF

DESCRIPTION: The PR disables the non-main db related features. The non-main db related features were introduced in #7203.

marcocitus reviewed Sep 19, 2023

View reviewed changes

src/backend/distributed/commands/extension.c Outdated Show resolved Hide resolved

marcocitus reviewed Sep 19, 2023

View reviewed changes

src/backend/distributed/transaction/remote_transaction.c Outdated Show resolved Hide resolved

marcocitus reviewed Sep 19, 2023

View reviewed changes

src/backend/distributed/transaction/remote_transaction.c Show resolved Hide resolved

marcocitus reviewed Sep 19, 2023

View reviewed changes

src/backend/distributed/transaction/transaction_management.c Outdated Show resolved Hide resolved

marcocitus changed the title ~~Adds 2PC distributed commands to pools~~ Adds 2PC distributed commands from other databases Sep 19, 2023

halilozanakgul force-pushed the pools_2pc branch 2 times, most recently from 7a33f0e to 60ec41d Compare September 20, 2023 13:23

marcoslot reviewed Oct 11, 2023

View reviewed changes

onurctirtir reviewed Oct 12, 2023

View reviewed changes

src/backend/distributed/metadata/metadata_sync.c Outdated Show resolved Hide resolved

onurctirtir reviewed Oct 12, 2023

View reviewed changes

onurctirtir reviewed Oct 13, 2023

View reviewed changes

src/backend/distributed/transaction/transaction_management.c Outdated Show resolved Hide resolved

JelteF approved these changes Oct 27, 2023

View reviewed changes

JelteF reviewed Oct 27, 2023

View reviewed changes

src/test/regress/sql/other_databases.sql Show resolved Hide resolved

JelteF mentioned this pull request Oct 27, 2023

Support role commands from any node #7278

Merged

onurctirtir reviewed Oct 30, 2023

View reviewed changes

JelteF self-requested a review October 30, 2023 10:08

JelteF reviewed Nov 8, 2023

View reviewed changes

src/backend/distributed/transaction/transaction_recovery.c Show resolved Hide resolved

JelteF suggested changes Nov 8, 2023

View reviewed changes

src/backend/distributed/transaction/transaction_recovery.c Outdated Show resolved Hide resolved

src/backend/distributed/transaction/transaction_recovery.c Outdated Show resolved Hide resolved

halilozanakgul force-pushed the pools_2pc branch from 57c44b1 to b0b6f3e Compare November 17, 2023 12:06

halilozanakgul force-pushed the pools_2pc branch from b9d34a6 to b5606fa Compare December 1, 2023 13:44

halilozanakgul marked this pull request as ready for review December 5, 2023 08:46

halilozanakgul force-pushed the pools_2pc branch from 5a2f254 to e1f8b7a Compare December 6, 2023 09:04

JelteF reviewed Dec 13, 2023

View reviewed changes

src/backend/distributed/shared_library_init.c Outdated Show resolved Hide resolved

JelteF reviewed Dec 13, 2023

View reviewed changes

src/backend/distributed/metadata/distobject.c Show resolved Hide resolved

JelteF reviewed Dec 13, 2023

View reviewed changes

src/backend/distributed/transaction/remote_transaction.c Outdated Show resolved Hide resolved

JelteF reviewed Dec 13, 2023

View reviewed changes

JelteF reviewed Dec 18, 2023

View reviewed changes

src/backend/distributed/transaction/remote_transaction.c Show resolved Hide resolved

JelteF reviewed Dec 18, 2023

View reviewed changes

src/backend/distributed/metadata/distobject.c Show resolved Hide resolved

halilozanakgul force-pushed the pools_2pc branch from 511d9c6 to b07bc2b Compare December 20, 2023 14:15

JelteF reviewed Dec 21, 2023

View reviewed changes

JelteF reviewed Dec 22, 2023

View reviewed changes

JelteF mentioned this pull request Dec 22, 2023

Add pytest test example about connecting to a worker #7386

Merged

halilozanakgul force-pushed the pools_2pc branch from f315f16 to 7124d7e Compare December 22, 2023 13:04

Adds 2PC distributed commands to pools

9bec1ca

halilozanakgul force-pushed the pools_2pc branch from adc12e1 to 9bec1ca Compare December 22, 2023 13:48

halilozanakgul added 3 commits December 22, 2023 16:56

fix test

76554b0

fix test

872e00f

Fix test

06c2a66

JelteF reviewed Dec 22, 2023

View reviewed changes

JelteF approved these changes Dec 22, 2023

View reviewed changes

halilozanakgul merged commit b877d60 into main Dec 22, 2023
156 checks passed

halilozanakgul deleted the pools_2pc branch December 22, 2023 16:19

ivyazmitinov reviewed May 9, 2024

View reviewed changes

ivyazmitinov mentioned this pull request May 9, 2024

7244/multi db connection improvements #7286

Open

eaydingol mentioned this pull request Feb 20, 2025

Disable nonmaindb interface #7905

Merged

eaydingol added a commit that referenced this pull request Feb 21, 2025

Disable nonmaindb interface (#7905)

117bd1d

DESCRIPTION: The PR disables the non-main db related features. The non-main db related features were introduced in #7203.

Adds 2PC distributed commands from other databases #7203

Adds 2PC distributed commands from other databases #7203

Conversation

halilozanakgul commented Sep 14, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

onurctirtir Oct 17, 2023 • edited Loading

Choose a reason for hiding this comment

JelteF left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marcoslot Nov 2, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Nov 17, 2023 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JelteF Dec 21, 2023 • edited Loading

Choose a reason for hiding this comment

JelteF Dec 18, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JelteF Dec 21, 2023 • edited Loading

Choose a reason for hiding this comment

JelteF Dec 21, 2023 • edited Loading

Choose a reason for hiding this comment

JelteF Dec 21, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JelteF Dec 22, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JelteF left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

halilozanakgul commented Sep 14, 2023 •

edited

Loading

onurctirtir Oct 17, 2023 •

edited

Loading

marcoslot Nov 2, 2023 •

edited

Loading

codecov bot commented Nov 17, 2023 •

edited

Loading

JelteF Dec 21, 2023 •

edited

Loading

JelteF Dec 18, 2023 •

edited

Loading

JelteF Dec 21, 2023 •

edited

Loading

JelteF Dec 21, 2023 •

edited

Loading

JelteF Dec 21, 2023 •

edited

Loading

JelteF Dec 22, 2023 •

edited

Loading