From 4cae8568461517b32b1b555ac58e32a0ee3db9e2 Mon Sep 17 00:00:00 2001 From: Onder Kalaci Date: Tue, 11 Sep 2018 14:14:44 +0300 Subject: [PATCH] Relax assertion on transaction abort on PREPARE step In case a failure happens when a transaction is failed on PREPARE, we used to hit an assertion for ensuring there is no pending activity on the connection. However, that's not true after the changes in #2031. Thus, we've replaced the assertion with a more generic function call to consume any pending activity, if exists. --- .../distributed/transaction/remote_transaction.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/src/backend/distributed/transaction/remote_transaction.c b/src/backend/distributed/transaction/remote_transaction.c index f8eaf3d74..7dd830566 100644 --- a/src/backend/distributed/transaction/remote_transaction.c +++ b/src/backend/distributed/transaction/remote_transaction.c @@ -528,8 +528,20 @@ FinishRemoteTransactionPrepare(struct MultiConnection *connection) transaction->transactionState = REMOTE_TRANS_PREPARED; } - result = GetRemoteCommandResult(connection, raiseErrors); - Assert(!result); + /* + * Try to consume results of PREPARE TRANSACTION command. If we don't + * succeed, rollback the transaction. Note that we've not committed on + * any node yet, and we're not sure about the state of the worker node. + * So rollbacking seems to be the safest action if the worker is + * in a state where it can actually rollback. + */ + if (!ClearResults(connection, raiseErrors)) + { + ereport(ERROR, (errmsg("failed to prepare transaction '%s' on host %s:%d", + transaction->preparedName, connection->hostname, + connection->port), + errhint("Try re-running the command."))); + } }