* ProcessBatchUpdate iterates over the updates array and executes each * update in a subtransaction, to allow us to continue after an error. * * If batchSpec->isOrdered is false, we continue with remaining tasks on * error. * * Using subtransactions is slightly different from Mongo, which effectively * does each update operation in a separate transaction, but it has roughly * the same over
| 1607 | * the same overall UX. |
| 1608 | */ |
| 1609 | static void |
| 1610 | ProcessBatchUpdate(MongoCollection *collection, BatchUpdateSpec *batchSpec, |
| 1611 | text *transactionId, BatchUpdateResult *batchResult, |
| 1612 | ExprEvalState *stateForSchemaValidation, |
| 1613 | WriteMode writeMode) |
| 1614 | { |
| 1615 | MemoryContext oldContext = MemoryContextSwitchTo(batchResult->resultMemoryContext); |
| 1616 | BuildUpdates(batchSpec); |
| 1617 | MemoryContextSwitchTo(oldContext); |
| 1618 | |
| 1619 | /* Check if we can inline the updates */ |
| 1620 | if (transactionId == NULL && collection->shardKey == NULL) |
| 1621 | { |
| 1622 | /* Technically ShareLock is okay here since we use SPI internally for the updates |
| 1623 | * However, if we end up building the AST directly, then easier to use RowExclusiveLock. |
| 1624 | */ |
| 1625 | batchSpec->shardTableOid = TryGetCollectionShardTable(collection, |
| 1626 | RowExclusiveLock); |
| 1627 | } |
| 1628 | |
| 1629 | List *updates = batchSpec->updates; |
| 1630 | bool isOrdered = batchSpec->isOrdered; |
| 1631 | |
| 1632 | /* We are in sharded scenario so we need to go through the planner to do the writes and then call the worker. */ |
| 1633 | bool forceInlineWrites = false; |
| 1634 | ProcessBatchUpdateCore(collection, updates, transactionId, batchResult, isOrdered, |
| 1635 | forceInlineWrites, stateForSchemaValidation, |
| 1636 | writeMode); |
| 1637 | } |
| 1638 | |
| 1639 | |
| 1640 | /* |
no test coverage detected