apache / shardingsphere

Empowering Data Intelligence with Distributed SQL for Sharding, Scalability, and Security Across All Databases.
Apache License 2.0
20.02k stars 6.77k forks source link

In READWRITE_SPLITTING mode,transaction commit is error #21237

Open peilinqian opened 2 years ago

peilinqian commented 2 years ago

Bug Report

For English only, other languages will not accept.

Before report a bug, make sure you have:

Please pay attention on issues you submitted, because we maybe need more details. If no response anymore and we cannot reproduce it on current information, we will close it.

Please answer these questions before submitting your issue. Thanks!

Which version of ShardingSphere did you use?

we find java version: java8, full_version=1.8.0_342, full_path=/home/peilq_sharding/bisheng-jdk1.8.0_342//bin/java ShardingSphere-5.2.1-SNAPSHOT Commit ID: dirty-4114e7ee4cbe5923c2b403a3e86d1f23355cadf3 Commit Message: Fix parse exception when execute insert statement with negative value (#21197) Branch: 4114e7ee4cbe5923c2b403a3e86d1f23355cadf3 Build time: 2022-09-27T16:37:07+0800

we find java version: java8, full_version=1.8.0_282, full_path=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.282.b08-1.el7_9.x86_64/bin/java ShardingSphere-5.2.1-SNAPSHOT Commit ID: dirty-bcde6f374c4a3a025173fbc9f6d0e66ed686a042 Commit Message: Fix fetch forward all error in openGauss(#21421) (#21471) Branch: bcde6f374c4a3a025173fbc9f6d0e66ed686a042 Build time: 2022-10-11T19:13:56+0800

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

ShardingSphere-Proxy

Expected behavior

In READWRITE_SPLITTING mode,transaction commit is normal

Actual behavior

test_db=> begin;
BEGIN
test_db=> insert into t_rw values(6,6,60,'test6');
INSERT 0 1
test_db=> select * from t_rw;
 id | c_id | a  |   b
----+------+----+-------
  1 |    1 | 10 | test1
  1 |    2 | 10 | test1
  2 |    2 | 20 | test2
  3 |    3 | 10 | test3
  4 |    4 | 40 | test4
  5 |    5 | 50 | test5
  6 |    6 | 60 | test6
  6 |    6 | 60 | test6
(8 rows)

test_db=> select * from t_rw;
 id | c_id | a  |   b
----+------+----+-------
  1 |    1 | 10 | test1
  1 |    2 | 10 | test1
  2 |    2 | 20 | test2
  3 |    3 | 10 | test3
  4 |    4 | 40 | test4
  5 |    5 | 50 | test5
  6 |    6 | 60 | test6
  6 |    6 | 60 | test6
(8 rows)

test_db=> end;
COMMIT

READWRITE_SPLITTING DB

split_db=> begin;
BEGIN
split_db=> insert into t_rw values(6,6,60,'test6');
INSERT 0 1
split_db=> select * from t_rw;
 id | c_id | a  |   b
----+------+----+-------
  1 |    1 | 10 | test1
  1 |    2 | 10 | test1
  2 |    2 | 20 | test2
  3 |    3 | 10 | test3
  4 |    4 | 40 | test4
  5 |    5 | 50 | test5
(6 rows)

split_db=> select * from t_rw;
 id | c_id | a  |   b
----+------+----+-------
  1 |    1 | 10 | test1
  1 |    2 | 10 | test1
  2 |    2 | 20 | test2
  3 |    3 | 10 | test3
  4 |    4 | 40 | test4
  5 |    5 | 50 | test5
(6 rows)

split_db=> end;
ERROR:  javax.transaction.HeuristicMixedException
[INFO ] 2022-09-28 16:19:48.871 [Connection-4-ThreadExecutor] ShardingSphere-SQL - Actual SQL: read0_0 ::: select * from t_rw;
[ERROR] 2022-09-28 16:19:48.965 [Connection-4-ThreadExecutor] o.a.s.p.f.c.CommandExecutorTask - Exception occur:
javax.transaction.HeuristicMixedException: null
        at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1303)
        at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:128)
        at org.apache.shardingsphere.transaction.xa.XAShardingSphereTransactionManager.commit(XAShardingSphereTransactionManager.java:108)
        at org.apache.shardingsphere.proxy.backend.communication.jdbc.transaction.JDBCBackendTransactionManager.commit(JDBCBackendTransactionManager.java:79)
        at org.apache.shardingsphere.proxy.backend.communication.jdbc.transaction.JDBCBackendTransactionManager.commit(JDBCBackendTransactionManager.java:37)
        at org.apache.shardingsphere.proxy.backend.handler.transaction.TransactionBackendHandler.execute(TransactionBackendHandler.java:125)
        at org.apache.shardingsphere.proxy.frontend.opengauss.command.query.simple.OpenGaussComQueryExecutor.execute(OpenGaussComQueryExecutor.java:76)
        at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.executeCommand(CommandExecutorTask.java:111)
        at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.run(CommandExecutorTask.java:78)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:750)
        Suppressed: org.opengauss.xa.PGXAException: Error preparing transaction. prepare xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:96c7:63340291:63, node_name=1, branch_uid=0:ffff7f000001:96c7:63340291:68, subordinatenodename=null, eis_name=0 >
                at org.opengauss.xa.PGXAConnection.prepare(PGXAConnection.java:360)
                at org.apache.shardingsphere.transaction.xa.spi.SingleXAResource.prepare(SingleXAResource.java:66)
                at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:214)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.doPrepare(BasicAction.java:2678)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.doPrepare(BasicAction.java:2628)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.prepare(BasicAction.java:2162)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1508)
                at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
                at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
                at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1295)
                ... 11 common frames omitted
        Caused by: org.opengauss.util.PSQLException: [90.90.44.175:40024/90.90.44.173:14000] ERROR: cannot execute PREPARE TRANSACTION during recovery
                at org.opengauss.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2901)
                at org.opengauss.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2630)
                at org.opengauss.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:362)
                at org.opengauss.jdbc.PgStatement.runQueryExecutor(PgStatement.java:562)
                at org.opengauss.jdbc.PgStatement.executeInternal(PgStatement.java:539)
                at org.opengauss.jdbc.PgStatement.execute(PgStatement.java:397)
                at org.opengauss.jdbc.PgStatement.executeWithFlags(PgStatement.java:339)
                at org.opengauss.jdbc.PgStatement.executeCachedSql(PgStatement.java:325)
                at org.opengauss.jdbc.PgStatement.executeWithFlags(PgStatement.java:302)
                at org.opengauss.jdbc.PgStatement.executeUpdate(PgStatement.java:275)
                at org.opengauss.xa.PGXAConnection.prepare(PGXAConnection.java:352)
                ... 20 common frames omitted
        Suppressed: org.opengauss.xa.PGXAException: Error preparing transaction. prepare xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:96c7:63340291:63, node_name=1, branch_uid=0:ffff7f000001:96c7:63340291:68, subordinatenodename=null, eis_name=0 >
                at org.opengauss.xa.PGXAConnection.prepare(PGXAConnection.java:360)
                at org.apache.shardingsphere.transaction.xa.spi.SingleXAResource.prepare(SingleXAResource.java:66)
                at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelPrepare(XAResourceRecord.java:214)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.doPrepare(BasicAction.java:2678)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.doPrepare(BasicAction.java:2628)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.prepare(BasicAction.java:2162)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1508)
                at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
                at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
                at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1295)
                ... 11 common frames omitted
        Caused by: org.opengauss.util.PSQLException: [90.90.44.175:40024/90.90.44.173:14000] ERROR: cannot execute PREPARE TRANSACTION during recovery
                at org.opengauss.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2901)
                at org.opengauss.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2630)
                at org.opengauss.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:362)
                at org.opengauss.jdbc.PgStatement.runQueryExecutor(PgStatement.java:562)
                at org.opengauss.jdbc.PgStatement.executeInternal(PgStatement.java:539)
                at org.opengauss.jdbc.PgStatement.execute(PgStatement.java:397)
                at org.opengauss.jdbc.PgStatement.executeWithFlags(PgStatement.java:339)
                at org.opengauss.jdbc.PgStatement.executeCachedSql(PgStatement.java:325)
                at org.opengauss.jdbc.PgStatement.executeWithFlags(PgStatement.java:302)
                at org.opengauss.jdbc.PgStatement.executeUpdate(PgStatement.java:275)
                at org.opengauss.xa.PGXAConnection.prepare(PGXAConnection.java:352)
                ... 20 common frames omitted
        Suppressed: org.opengauss.xa.PGXAException: Error rolling back prepared transaction. rollback xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:96c7:63340291:63, node_name=1, branch_uid=0:ffff7f000001:96c7:63340291:68, subordinatenodename=null, eis_name=0 >, preparedXid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:96c7:63340291:63, node_name=1, branch_uid=0:ffff7f000001:96c7:63340291:68, subordinatenodename=null, eis_name=0 >, currentXid={2}
                at org.opengauss.xa.PGXAConnection.rollback(PGXAConnection.java:464)
                at org.apache.shardingsphere.transaction.xa.spi.SingleXAResource.rollback(SingleXAResource.java:76)
                at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:362)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3037)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3016)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1986)
                at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1524)
                at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
                at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
                at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1295)
                ... 11 common frames omitted
        Caused by: org.opengauss.util.PSQLException: [90.90.44.175:40024/90.90.44.173:14000] ERROR: cannot execute ROLLBACK PREPARED during recovery
                at org.opengauss.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2901)
                at org.opengauss.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2630)
                at org.opengauss.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:362)
                at org.opengauss.jdbc.PgStatement.runQueryExecutor(PgStatement.java:562)
                at org.opengauss.jdbc.PgStatement.executeInternal(PgStatement.java:539)
                at org.opengauss.jdbc.PgStatement.execute(PgStatement.java:397)
                at org.opengauss.jdbc.PgStatement.executeWithFlags(PgStatement.java:339)
                at org.opengauss.jdbc.PgStatement.executeCachedSql(PgStatement.java:325)
                at org.opengauss.jdbc.PgStatement.executeWithFlags(PgStatement.java:302)
                at org.opengauss.jdbc.PgStatement.executeUpdate(PgStatement.java:275)
                at org.opengauss.xa.PGXAConnection.rollback(PGXAConnection.java:457)
                ... 20 common frames omitted

Reason analyze (If you can)

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

drop table if exists t_single;
create table t_single(id int,c_id int,a int,b text);
insert into t_single values (1,1,10,'test1'),(1,2,10,'test1'),(2,2,20,'test2'),
(3,3,10,'test3'),(4,4,40,'test4'),(5,5,50,'test5');
create index idx_rw on t_single(id);
select * from t_single;
select * from t_single;
select * from t_single;

begin;
insert into t_single values(6,6,60,'test6');
select * from t_single;
select * from t_single;
end;

Example codes for reproduce this issue (such as a github link).

peilinqian commented 2 years ago
split_db=> SHOW READWRITE_SPLITTING RULES ;
 name | auto_aware_data_source_name | write_data_source_query_enabled | write_data_source_name | read_data_source_names |   load_balancer_type    | load_balancer_props
------+-----------------------------+---------------------------------+------------------------+------------------------+-------------------------+---------------------
 ds_0 |                             |                                 | write_0                | read0_0                | TRANSACTION_ROUND_ROBIN |
 ds_1 |                             |                                 | write_1                | read1_0                | TRANSACTION_ROUND_ROBIN |
(2 rows)
rules:
  - !AUTHORITY
    users:
      - root@%:root
      - sharding@:sharding
    provider:
      type: ALL_PERMITTED
  - !TRANSACTION
    defaultType: XA
    providerType: Atomikos
schemaName: split_db
dataSources:
  write_0:
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 260
    minPoolSize: 1
    password: Test@123
    url: jdbc:opengauss://10.29.180.204:15000/tpccdb?batchMode=on
    username: tpccuser
  read0_0:
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 260
    minPoolSize: 1
    password: Test@123
    url: jdbc:opengauss://10.28.13.92:15000/tpccdb?batchMode=on
    username: tpccuser
  read0_1:
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 260
    minPoolSize: 1
    password: Test@123
    url: jdbc:opengauss://7.212.123.28:15000/tpccdb?batchMode=on
    username: tpccuser
  write_1:
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 260
    minPoolSize: 1
    password: Test@123
    url: jdbc:opengauss://10.29.180.204:16000/tpccdb?batchMode=on
    username: tpccuser
  read1_0:
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 260
    minPoolSize: 1
    password: Huawei@123
    url: jdbc:opengauss://10.28.13.92:16000/tpccdb?batchMode=on
    username: tpccuser
  read1_1:
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 260
    minPoolSize: 1
    password: Test@123
    url: jdbc:opengauss://7.212.123.28:16000/tpccdb?batchMode=on
    username: tpccuser
rules:
- !SHARDING
  tables:
    t_single:
      actualDataNodes: ds_0.t_single
    t_single_view:
      actualDataNodes: ds_0.t_single_view
    t_single_view_new:
      actualDataNodes: ds_0.t_single_view_new
    t_ssdb_tb:
      actualDataNodes: ds_${0..1}.t_ssdb_tb_${0..1}
      databaseStrategy:
        standard:
          shardingAlgorithmName: ds_database_inline
          shardingColumn: id
      tableStrategy:
        standard:
          shardingColumn: c_id
          shardingAlgorithmName: ts_t_ssdb_tb_inline
    t_ssdb_tb_view:
      actualDataNodes: ds_${0..1}.t_ssdb_tb_view_${0..1}
      databaseStrategy:
        standard:
          shardingAlgorithmName: ds_database_inline
          shardingColumn: id
      tableStrategy:
        standard:
          shardingColumn: c_id
          shardingAlgorithmName: ts_t_ssdb_tb_view_inline
    t_ssdb:
      actualDataNodes: ds_${0..1}.t_ssdb
      databaseStrategy:
        standard:
          shardingAlgorithmName: ds_database_inline
          shardingColumn: id
    t_ssdb_view:
      actualDataNodes: ds_${0..1}.t_ssdb_view
      databaseStrategy:
        standard:
          shardingAlgorithmName: ds_database_inline
          shardingColumn: id
    t_ssdb_tbo:
      actualDataNodes: ds_${0..1}.t_ssdb_tbo_${0..1}
      databaseStrategy:
        standard:
          shardingAlgorithmName: ds_database_inline
          shardingColumn: id
      tableStrategy:
        standard:
          shardingColumn: c_id
          shardingAlgorithmName: ts_t_ssdb_tbo_inline

  broadcastTables:
    - t_broadcast
    - t_broadcast_view
  bindingTables:
    - t_ssdb_tb, t_ssdb_tbo, t_ssdb_tb_view
  defaultTableStrategy:
    none:
  defaultDatabaseStrategy:
    none:
  shardingAlgorithms:
    ds_database_inline:
      type: INLINE
      props:
        algorithm-expression: ds_${id % 2}
        allow-range-query-with-inline-sharding: true
    ts_t_ssdb_tb_inline:
      type: INLINE
      props:
        algorithm-expression: t_ssdb_tb_${c_id % 2}
        allow-range-query-with-inline-sharding: true
    ts_t_ssdb_tbo_inline:
      type: INLINE
      props:
        algorithm-expression: t_ssdb_tbo_${c_id % 2}
        allow-range-query-with-inline-sharding: true
    ts_t_ssdb_tb_view_inline:
      type: INLINE
      props:
        algorithm-expression: t_ssdb_tb_view_${c_id % 2}
        allow-range-query-with-inline-sharding: true

- !READWRITE_SPLITTING
  dataSources:
    ds_0:
      staticStrategy:
        writeDataSourceName: write_0
        readDataSourceNames:
          - read0_0
          - read0_1
      loadBalancerName: roundRobin
    ds_1:
      staticStrategy:
        writeDataSourceName: write_1
        readDataSourceNames:
          - read1_0
          - read1_1
      loadBalancerName: roundRobin
  loadBalancers:
    roundRobin:
      type: TRANSACTION_ROUND_ROBIN
wsm12138 commented 2 years ago
rules:
- !READWRITE_SPLITTING
  dataSources:
    readwrite_ds:
      staticStrategy:
        writeDataSourceName: ds_0
        readDataSourceNames:
          - ds_1
      loadBalancerName: random
  loadBalancers:
    random:
      type: TRANSACTION_ROUND_ROBIN
wsm12138 commented 2 years ago

When i use loacl mode of trancation,it act normal

image image image
FlyingZC commented 2 years ago

I can't reproduce it locally.

sharding_db=> drop table if exists t_single;
DROP TABLE
sharding_db=> create table t_single(id int,c_id int,a int,b text);
CREATE TABLE
sharding_db=> insert into t_single values (1,1,10,'test1'),(1,2,10,'test1'),(2,2,20,'test2'),
(3,3,10,'test3'),(4,4,40,'test4'),(5,5,50,'test5');sharding_db->
INSERT 0 6
sharding_db=> create index idx_rw on t_single(id);
CREATE INDEX
sharding_db=> select * from t_single;
select * from t_single;
select * from t_single; id | c_id | a  |   b
----+------+----+-------
  1 |    1 | 10 | test1
  1 |    2 | 10 | test1
  2 |    2 | 20 | test2
  3 |    3 | 10 | test3
  4 |    4 | 40 | test4
  5 |    5 | 50 | test5
(6 rows)

sharding_db=>  id | c_id | a  |   b
----+------+----+-------
  1 |    1 | 10 | test1
  1 |    2 | 10 | test1
  2 |    2 | 20 | test2
  3 |    3 | 10 | test3
  4 |    4 | 40 | test4
  5 |    5 | 50 | test5
(6 rows)

sharding_db=>
 id | c_id | a  |   b
----+------+----+-------
  1 |    1 | 10 | test1
  1 |    2 | 10 | test1
  2 |    2 | 20 | test2
  3 |    3 | 10 | test3
  4 |    4 | 40 | test4
  5 |    5 | 50 | test5
(6 rows)

sharding_db=> begin;
BEGIN
sharding_db=> insert into t_single values(6,6,60,'test6');
INSERT 0 1
sharding_db=> select * from t_single;
 id | c_id | a  |   b
----+------+----+-------
  1 |    1 | 10 | test1
  1 |    2 | 10 | test1
  2 |    2 | 20 | test2
  3 |    3 | 10 | test3
  4 |    4 | 40 | test4
  5 |    5 | 50 | test5
(6 rows)

sharding_db=> select * from t_single;
end; id | c_id | a  |   b
----+------+----+-------
  1 |    1 | 10 | test1
  1 |    2 | 10 | test1
  2 |    2 | 20 | test2
  3 |    3 | 10 | test3
  4 |    4 | 40 | test4
  5 |    5 | 50 | test5
(6 rows)

sharding_db=>
COMMIT
sharding_db=> SHOW TRANSACTION RULE;
 default_type | provider_type | props
--------------+---------------+-------
 XA           | Narayana      |
(1 row)

sharding_db=>
image image
FlyingZC commented 2 years ago
image
FlyingZC commented 2 years ago

This error is suspicious: org.opengauss.xa.PGXAException: Error rolling back prepared transaction,I think it maybe the OG's problem,I found a similar question for reference: https://stackoverflow.com/questions/45867536/postgresql-xa-transaction-exception

wsm12138 commented 2 years ago

This error is suspicious: org.opengauss.xa.PGXAException: Error rolling back prepared transaction,I think it maybe the OG's problem,I found a similar question for reference: https://stackoverflow.com/questions/45867536/postgresql-xa-transaction-exception

Thanks for your reply,after reset max_prepared_transactions,use proxy execute above case ,i found nomatter use local mode or xa mode ,it act normal

peilinqian commented 2 years ago

This error is suspicious: org.opengauss.xa.PGXAException: Error rolling back prepared transaction,I think it maybe the OG's problem,I found a similar question for reference: https://stackoverflow.com/questions/45867536/postgresql-xa-transaction-exception

Thanks for your reply,after reset max_prepared_transactions,use proxy execute above case ,i found nomatter use local mode or xa mode ,it act normal

What is the value of max_prepared_transactions reset to?

wsm12138 commented 2 years ago

This error is suspicious: org.opengauss.xa.PGXAException: Error rolling back prepared transaction,I think it maybe the OG's problem,I found a similar question for reference: https://stackoverflow.com/questions/45867536/postgresql-xa-transaction-exception

Thanks for your reply,after reset max_prepared_transactions,use proxy execute above case ,i found nomatter use local mode or xa mode ,it act normal

What is the value of max_prepared_transactions reset to?

set max_prepared_transactions=5000;

wsm12138 commented 2 years ago

Maybe it is related about variables of openGauss like synchronous_commit & synchronous_standby_names ?

Further validation is needed.

wsm12138 commented 2 years ago

Maybe it is related about variables of openGauss like synchronous_commit & synchronous_standby_names ?

Further validation is needed.

@peilinqian can you provide your value of variables of openGauss like synchronous_commit & synchronous_standby_names ?

peilinqian commented 2 years ago

Maybe it is related about variables of openGauss like synchronous_commit & synchronous_standby_names ? Further validation is needed.

@peilinqian can you provide your value of variables of openGauss like synchronous_commit & synchronous_standby_names ? execute this SQL in standby database; select name, setting from pg_settings order by 1,2; set guc parameter in standby database gs_guc reload -D {dn dir} -c "log_statement = all" gs_guc reload -D {dn dir} -c "log_min_duration_statement = 0 "

FlyingZC commented 2 years ago

When configuring an XA transaction, ss executes the XA statement on each openGauss node within the transaction. But currently openGauss does not support executing XA statements on the read database, which should be a problem that openGauss needs to solve, I think.