This is an automated email from the ASF dual-hosted git repository. avamingli pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/cloudberry.git
commit 840ea494aa0e99bf5483c98c4274e58dfd477a76 Author: Soumyadeep Chakraborty <[email protected]> AuthorDate: Fri Dec 16 18:16:45 2022 -0800 ao/co: Clarify tuple_lock API This commit confirms that the tuple_lock API can be safely left unimplemented for AO/CO tables. See below for details: (1) UPSERT: ExecOnConflictUpdate() calls this, but clearly upsert is not supported for AO/CO tables. (2) DELETE and UPDATE triggers: GetTupleForTrigger() calls this, but clearly these trigger types are not supported for AO/CO tables. (3) Logical replication: RelationFindReplTupleByIndex() and RelationFindReplTupleSeq() calls this, but clearly we don't support logical replication yet for GPDB. (4) For DELETEs/UPDATEs, when a state of TM_Updated is returned from table_tuple_delete() and table_tuple_update() respectively, this API is invoked. However, that is impossible for AO/CO tables as an AO/CO tuple cannot be deleted/updated while another transaction is updating it (see CdbTryOpenTable()). (5) Row-level locking (SELECT FOR ..): ExecLockRows() calls this but a plan containing the LockRows plan node is never generated for AO/CO tables. In fact, we lock at the table level instead. See 6ebce733317 for details. pstate->p_canOptSelectLockingClause = false; is done in addRangeTableEntry() for AO/CO tables, which prevents such plans. Also, ORCA falls back to planner when presented with a query carrying a locking clause. --- src/backend/access/aocs/aocsam_handler.c | 28 ++++++++++++++++++++-- .../access/appendonly/appendonlyam_handler.c | 28 ++++++++++++++++++++-- 2 files changed, 52 insertions(+), 4 deletions(-) diff --git a/src/backend/access/aocs/aocsam_handler.c b/src/backend/access/aocs/aocsam_handler.c index d91c913f87..3ebf5d6a82 100644 --- a/src/backend/access/aocs/aocsam_handler.c +++ b/src/backend/access/aocs/aocsam_handler.c @@ -1175,14 +1175,38 @@ aoco_tuple_update(Relation relation, ItemPointer otid, TupleTableSlot *slot, return result; } +/* + * This API is called for a variety of purposes, which are either not supported + * for AO/CO tables or not supported for GPDB in general: + * + * (1) UPSERT: ExecOnConflictUpdate() calls this, but clearly upsert is not + * supported for AO/CO tables. + * + * (2) DELETE and UPDATE triggers: GetTupleForTrigger() calls this, but clearly + * these trigger types are not supported for AO/CO tables. + * + * (3) Logical replication: RelationFindReplTupleByIndex() and + * RelationFindReplTupleSeq() calls this, but clearly we don't support logical + * replication yet for GPDB. + * + * (4) For DELETEs/UPDATEs, when a state of TM_Updated is returned from + * table_tuple_delete() and table_tuple_update() respectively, this API is invoked. + * However, that is impossible for AO/CO tables as an AO/CO tuple cannot be + * deleted/updated while another transaction is updating it (see CdbTryOpenTable()). + * + * (5) Row-level locking (SELECT FOR ..): ExecLockRows() calls this but a plan + * containing the LockRows plan node is never generated for AO/CO tables. In fact, + * we lock at the table level instead. + */ static TM_Result aoco_tuple_lock(Relation relation, ItemPointer tid, Snapshot snapshot, TupleTableSlot *slot, CommandId cid, LockTupleMode mode, LockWaitPolicy wait_policy, uint8 flags, TM_FailureData *tmfd) { - /* GPDB_12_MERGE_FIXME: not supported. Can this function be left out completely? Or ereport()? */ - elog(ERROR, "speculative insertion not supported on AO tables"); + ereport(ERROR, + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), + errmsg("tuple locking is not supported on appendoptimized tables"))); } static void diff --git a/src/backend/access/appendonly/appendonlyam_handler.c b/src/backend/access/appendonly/appendonlyam_handler.c index 4f4fd969dd..c86c143963 100644 --- a/src/backend/access/appendonly/appendonlyam_handler.c +++ b/src/backend/access/appendonly/appendonlyam_handler.c @@ -1131,14 +1131,38 @@ appendonly_tuple_update(Relation relation, ItemPointer otid, TupleTableSlot *slo return result; } +/* + * This API is called for a variety of purposes, which are either not supported + * for AO/CO tables or not supported for GPDB in general: + * + * (1) UPSERT: ExecOnConflictUpdate() calls this, but clearly upsert is not + * supported for AO/CO tables. + * + * (2) DELETE and UPDATE triggers: GetTupleForTrigger() calls this, but clearly + * these trigger types are not supported for AO/CO tables. + * + * (3) Logical replication: RelationFindReplTupleByIndex() and + * RelationFindReplTupleSeq() calls this, but clearly we don't support logical + * replication yet for GPDB. + * + * (4) For DELETEs/UPDATEs, when a state of TM_Updated is returned from + * table_tuple_delete() and table_tuple_update() respectively, this API is invoked. + * However, that is impossible for AO/CO tables as an AO/CO tuple cannot be + * deleted/updated while another transaction is updating it (see CdbTryOpenTable()). + * + * (5) Row-level locking (SELECT FOR ..): ExecLockRows() calls this but a plan + * containing the LockRows plan node is never generated for AO/CO tables. In fact, + * we lock at the table level instead. + */ static TM_Result appendonly_tuple_lock(Relation relation, ItemPointer tid, Snapshot snapshot, TupleTableSlot *slot, CommandId cid, LockTupleMode mode, LockWaitPolicy wait_policy, uint8 flags, TM_FailureData *tmfd) { - /* GPDB_12_MERGE_FIXME: not supported. Can this function be left out completely? Or ereport()? */ - elog(ERROR, "speculative insertion not supported on AO tables"); + ereport(ERROR, + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), + errmsg("tuple locking is not supported on appendoptimized tables"))); } static void --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
