A txn's heartbeat loop is generally stopped when, upon a successful
request, the response's txn is no longer PENDING. This was insufficient;
the loop should always be closed after an EndTransaction(commit=false),
regardless of whether it results in success or error.
The heartbeat loop happens to be currently closed by the context
cancelation that the db.Txn() API performs, but that is going away.

This fixes cockroachdb#26434 - TestTxnCoordSenderRetries had become flaky after cockroachdb#25541
because cockroachdb#25441 caused EndTransactions to be sent in some situations
where they weren't before. What's going on in that test is that a
subtest was leaking a heartbeat loop that was stopped after the subtest
finished; the EndTxn sent when the loop finally was being stopped was
interfering with a CommandFilter installed by a different subtest.
Before cockroachdb#25441, the first subtest was waiting for the heartbeat loop to
be done because of its own CommandFilter. However, with cockroachdb#25441, the
first subtest's CommandFilter was being satisfied by a different, newly
introduced EndTransaction.

Release note: None

A txn's heartbeat loop is generally stopped when, upon a successful
request, the response's txn is no longer PENDING. This was insufficient;
the loop should always be closed after an EndTransaction(commit=false),
regardless of whether it results in success or error.
The heartbeat loop happens to be currently closed by the context
cancelation that the db.Txn() API performs, but that is going away.

This fixes cockroachdb#26434 - TestTxnCoordSenderRetries had become flaky after cockroachdb#25541
because cockroachdb#25441 caused EndTransactions to be sent in some situations
where they weren't before. What's going on in that test is that a
subtest was leaking a heartbeat loop that was stopped after the subtest
finished; the EndTxn sent when the loop finally was being stopped was
interfering with a CommandFilter installed by a different subtest.
Before cockroachdb#25441, the first subtest was waiting for the heartbeat loop to
be done because of its own CommandFilter. However, with cockroachdb#25441, the
first subtest's CommandFilter was being satisfied by a different, newly
introduced EndTransaction.

Release note: None

A txn's heartbeat loop is generally stopped when, upon a successful
request, the response's txn is no longer PENDING. This was insufficient;
the loop should always be closed after an EndTransaction(commit=false),
regardless of whether it results in success or error.
The heartbeat loop happens to be currently closed by the context
cancelation that the db.Txn() API performs, but that is going away.

This fixes cockroachdb#26434 - TestTxnCoordSenderRetries had become flaky after cockroachdb#25541
because cockroachdb#25441 caused EndTransactions to be sent in some situations
where they weren't before. What's going on in that test is that a
subtest was leaking a heartbeat loop that was stopped after the subtest
finished; the EndTxn sent when the loop finally was being stopped was
interfering with a CommandFilter installed by a different subtest.
Before cockroachdb#25441, the first subtest was waiting for the heartbeat loop to
be done because of its own CommandFilter. However, with cockroachdb#25441, the
first subtest's CommandFilter was being satisfied by a different, newly
introduced EndTransaction.

Release note: None

26479: kv: stop the heartbeat loop on rollback errors r=andreimatei a=andreimatei

A txn's heartbeat loop is generally stopped when, upon a successful
request, the response's txn is no longer PENDING. This was insufficient;
the loop should always be closed after an EndTransaction(commit=false),
regardless of whether it results in success or error.
The heartbeat loop happens to be currently closed by the context
cancelation that the db.Txn() API performs, but that is going away.

This fixes #26434 - TestTxnCoordSenderRetries had become flaky after #25541
because #25441 caused EndTransactions to be sent in some situations
where they weren't before. What's going on in that test is that a
subtest was leaking a heartbeat loop that was stopped after the subtest
finished; the EndTxn sent when the loop finally was being stopped was
interfering with a CommandFilter installed by a different subtest.
Before #25441, the first subtest was waiting for the heartbeat loop to
be done because of its own CommandFilter. However, with #25441, the
first subtest's CommandFilter was being satisfied by a different, newly
introduced EndTransaction.

Release note: None

26516: sql: disable optimizer if force-lookup-joins flag set r=RaduBerinde a=RaduBerinde

The experimental flag to force lookup joins doesn't work with the
optimizer (it is disabled on opt-generated plans). To allow the flag
to still function for now, we disable the optimizer if the flag is
set.

Release note: None

Co-authored-by: Andrei Matei <andrei@cockroachlabs.com>
Co-authored-by: Radu Berinde <radu@cockroachlabs.com>