yugabyte/yugabyte-db

Jira Link: DB-21804 Description In one of the customer setups, it looked like we ran into a case where rocksdbs for all peers hosted by that node were deleted/didn't exist after os patching activity, and the peers started off fresh from op 0.0. Though thing srecover from here automatically (either leader serves the ops, or removes the peer from the quorum if unable to serve), it would be good to flag such instances and raise appropriate warning messages. Issue Type kind/enhancement Warning: Please confirm that this issue does not contain any sensitive information I confirm this issue does not contain any sensitive information.

Jira Link: DB-21716 Created by opus 4.8 Problem For a query whose IN predicates fully determine a hash primary key, e.g. CREATE TABLE foo (h1 int, h2 int, PRIMARY KEY ((h1, h2) HASH)); SELECT * FROM foo WHERE h1 IN (0,1) AND h2 IN (0,1); every target row is a complete, known primary key — the four combinations (0,0),(0,1),(1,0),(1,1). This is effectively a batch of point lookups. Instead, the storage layer executes it through HybridScanChoices, the general option-iteration engine, rather than the direct ybctid/SeekTuple point-read path. This issue is to investigate whether the fully-bound case can take the cheaper point-lookup path, and whether it is worth doing. User impact The query does the same RocksDB seeks either way, so there is no extra I/O, but HybridScanChoices adds per-target CPU bookkeeping (SkipTargetsUpTo, IncrementScanTargetAtOptionList, ValidateHashGroup, CurrentTargetMatchesKey, group-end/option-group handling) to do what is fundamentally N point seeks. Root cause /

Jira Link: DB-21409 Problem In AbortSubTransaction() (src/postgres/src/backend/access/transam/xact.c:5604), the call chain on subtransaction abort flushes buffered operations to the tserver before clearing them, instead of just dropping them: AbortSubTransaction() // xact.c:5604 ... AtSubAbort_Snapshot(s->nestingLevel) // xact.c:5743 -> YBCOnActiveSnapshotChange() // snapmgr.c:1172 -> YBCPgRestoreReadPoint(handle) // snapmgr.c:326 -> PgApiImpl::RestoreReadPoint() // pggate.cc:2682 -> FlushBufferedOperations(...) // pggate.cc:2683 <-- FLUSH (not clear) -> pg_txn_manager_->RestoreReadPoint // pggate.cc:2684 YBCRollbackToSubTransaction(s->subTransactionId) // xact.c:5746 -> PgApiImpl::RollbackToSubTransaction() // pggate.cc:2258 -> ClearSessionState() // pggate.cc:2259 -> pg_session_->ClearState()

Jira Link: DB-20234 Description WARNING: Batched COPY is not supported in transaction blocks. Defaulting to using one transaction for the entire copy. HINT: Either run this COPY outside of a transaction block or set rows_per_transaction option to `0` to disable batching and remove this warning. CONTEXT: SQL statement "COPY shell_output FROM PROGRAM ERROR: Commit of transaction that requires restart is not allowed STATEMENT: COMMIT; Issue Type kind/bug Warning: Please confirm that this issue does not contain any sensitive information I confirm this issue does not contain any sensitive information.

Jira Link: DB-19966 Description Plan is to pass this flag with a value of true for instances running in YBM. That is, the code that starts these processes on YBM will set this flag to true. Flag should default to false. For now, nothing will be reading this flag. We plan to use this flag to roll out some features to YBM first and only later to YBA/OSS. Probably want to put this in common_flags.h or the equivalent (We need the flag defined first before YBM can start passing it.) backport this to 2024.2, 2025.1, 2025.2 Issue Type kind/enhancement Warning: Please confirm that this issue does not contain any sensitive information I confirm this issue does not contain any sensitive information.