From 096bbba1ccfab0e401201ac65d22f05df905abcc Mon Sep 17 00:00:00 2001 From: reshke Date: Wed, 3 Jun 2026 15:04:59 +0000 Subject: [PATCH] Fix for CDBD expand with concurrent distributed tx An duct tape for this was already added as fc8aab8, through redo path was not patched there. Copy same logic into redoDistributedCommitRecord function boby. --- src/backend/cdb/cdbdtxrecovery.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/backend/cdb/cdbdtxrecovery.c b/src/backend/cdb/cdbdtxrecovery.c index 605ce323ddb..1082e5c0fe2 100644 --- a/src/backend/cdb/cdbdtxrecovery.c +++ b/src/backend/cdb/cdbdtxrecovery.c @@ -493,6 +493,17 @@ redoDistributedCommitRecord(DistributedTransactionId gxid) int i; bool is_hot_standby_qd = IS_HOT_STANDBY_QD(); + /* + * The coordinator may execute write DTX during gpexpand, so the newly + * added segment may contain DTX info in checkpoint XLOG. However, this step + * is useless and should be avoided for segments, or fatal may be thrown since + * max_tm_gxacts is 0 in segments. See also fc8aab88d + */ + if (ConvertMasterDataDirToSegment && !IS_QUERY_DISPATCHER()) + { + return; + } + /* * Only the startup process can be modifying shmNumCommittedGxacts * and shmCommittedGxidArray. So should be OK reading the value w/o lock.