CUBRID Code-Analysis Coverage — Map of What's Documented and What's Open

What this doc is (and isn’t)

This is the coverage map for knowledge/code-analysis/cubrid/. It answers a single question: what’s been written, and what’s still open?

It deliberately is not:

• A per-doc catalog with summaries — that’s README.md, generated from each doc’s summary: frontmatter.
• An architectural map of the system — that’s cubrid-architecture-overview.md, with one Mermaid diagram per axis and links into every detail doc.
• A complete enumeration of every CUBRID source file. Coverage here is pitched at subsystem granularity. If a subsystem has a dedicated detail doc (or is a named subsection in an overview doc), it counts as covered; we don’t track per-symbol gaps.

Use this doc when planning the next batch of analyses, or when you want a single-screen answer to “is X documented yet?”.

Coverage at a glance

Roughly 85 EN detail docs plus 8 subcategory overviews cover the storage engine, query pipeline, transaction/recovery axis, distribution/HA layer, DDL/schema, the two PL runtimes (JavaSP and PL/CSQL), and most cross-cutting infrastructure. Korean mirrors track the EN tree under knowledge/ko/code-analysis/cubrid/.

No remaining gaps at subsystem granularity. The utilities-and-admin cluster (csql, the cubrid admin verbs, the cub_master daemon, unloaddb / loaddb / compactdb / backup-restore, checksumdb, migrate, loadjava, and the small standalone helpers) is fully covered. The PL family is fully covered (the three siblings: javasp, plcsql, server-bridge). All other subsystems (storage, query, transactions, catalog/DDL, distribution/HA, i18n) were already covered in earlier batches.

Everything else is either covered or an intentional non-goal (see last section).

Coverage by subsystem

Server architecture

Covered. Process model and broker/CAS/server fan-in (cubrid-overview-server-architecture.md, cubrid-broker.md, cubrid-server-session.md, cubrid-network-protocol.md, cubrid-thread-worker-pool.md, cubrid-thread-manager-ng.md, cubrid-sa-cs-runtime.md, cubrid-boot.md, cubrid-system-parameters.md, cubrid-error-management.md, cubrid-monitoring.md, cubrid-dbi-cci.md).

Open. None at subsystem granularity. (The cub_master daemon itself now has its own doc — cubrid-master-process.md — which covers boot sequence, select-loop connection registry, request opcode dispatch, and the optional server_monitor C++ auto-restart supervisor; the HA-replication subsystem layered on top remains in cubrid-heartbeat.md.)

Storage engine

Covered. Full layered stack (cubrid-overview-storage-engine.md, cubrid-disk-manager.md, cubrid-page-buffer-manager.md, cubrid-double-write-buffer.md, cubrid-heap-manager.md, cubrid-btree.md, cubrid-extendible-hash.md, cubrid-overflow-file.md, cubrid-lob.md, cubrid-tde.md).

Open. None at subsystem granularity. The AREA slab pool — formerly tracked here — has moved to the Base / infrastructure section below alongside the lock-free primitives, since it is a memory-allocator concern that any layer can use rather than a storage layer.

Base / infrastructure (memory allocators + lock-free primitives)

Covered. (cubrid-overview-base-infra.md, cubrid-private-allocator.md, cubrid-common-area.md, cubrid-lockfree-overview.md, cubrid-lockfree-transaction.md, cubrid-lockfree-bitmap.md, cubrid-lockfree-circular-queue.md, cubrid-lockfree-freelist.md, cubrid-lockfree-hashmap.md).

The subcategory groups the src/base/ substrate that every other section composes with — the per-thread Lea-heap private allocator, the AREA slab pool for fixed-size objects, and the six-doc lock-free family anchored on the transactional reclamation spine.

Open. Other src/base/ candidates (resource tracker, custom heaps internals, mem_block allocators) are currently described inline by cubrid-private-allocator.md and cubrid-common-area.md; whether they deserve their own per-doc treatment is open.

Query processing

Covered. Full parse → execute pipeline (cubrid-overview-query-processing.md, cubrid-parser.md, cubrid-semantic-check.md, cubrid-query-rewrite.md, cubrid-query-optimizer.md, cubrid-xasl-generator.md, cubrid-xasl-cache.md, cubrid-query-executor.md, cubrid-query-evaluator.md, cubrid-scan-manager.md, cubrid-list-file.md, cubrid-scalar-functions.md, cubrid-external-sort.md, cubrid-hash-join.md, cubrid-post-processing.md, cubrid-runtime-memoization.md, cubrid-partition.md, cubrid-cursor.md, cubrid-serial.md, cubrid-parallel-query.md, cubrid-json-table.md, cubrid-show-commands.md).

End-to-end synthesis lives in cubrid-rpath-select.md.

Open. None at subsystem granularity. Method-call as a SCAN_TYPE is covered briefly in cubrid-scan-manager.md; the callback protocol sitting underneath it is in the PL section below.

Transactions, concurrency, recovery

Covered. Full ARIES-style stack (cubrid-overview-txn-recovery.md, cubrid-mvcc.md, cubrid-vacuum.md, cubrid-lock-manager.md, cubrid-transaction.md, cubrid-log-manager.md, cubrid-prior-list.md, cubrid-checkpoint.md, cubrid-recovery-manager.md, cubrid-flashback.md).

End-to-end synthesis lives in cubrid-rpath-write.md and cubrid-rpath-recovery.md.

Open. None at subsystem granularity.

Catalog, schema, DDL

Covered. (cubrid-overview-ddl-schema.md, cubrid-catalog-manager.md, cubrid-class-object.md, cubrid-locator.md, cubrid-ddl-execution.md, cubrid-trigger.md, cubrid-statistics.md, cubrid-authentication.md).

Open. None at subsystem granularity.

Distribution and HA

Covered. (cubrid-overview-replication-ha.md, cubrid-ha-replication.md, cubrid-heartbeat.md, cubrid-cdc.md, cubrid-2pc.md, cubrid-backup-restore.md).

Open. checksumdb — the HA replica vs master row-checksum verifier — pairs naturally here but is an executable, so it belongs in the CLI batch.

PL family

Covered. (cubrid-overview-pl-language.md, cubrid-pl-javasp.md, cubrid-pl-plcsql.md, cubrid-pl-server-bridge.md).

The PL family is now a three-sibling set: JavaSP and PL/CSQL each get their own runtime doc, and cubrid-pl-server-bridge.md covers the shared mid-execution callback channel they both ride on (the METHOD_CALLBACK_* opcode taxonomy, the CAS-side cubmethod::callback_handler::callback_dispatch for Path A, the server-side cubpl::executor::response_callback_command for Path B, the compile-time GET_SQL_SEMANTICS / GET_GLOBAL_SEMANTICS round-trips PL/CSQL uses for embedded-SQL validation, the recursion guard, and the tran_begin/end_libcas_function bracketing). The two existing PL docs cross-ref into it from their callback-related sections.

Open. None at subsystem granularity. The loadjava utility — the “install a JAR into the catalog so JavaSP can resolve it” tool — is a CLI surface and lives in the utilities batch below even though it’s PL-adjacent.

Utilities and admin CLI

Covered. (cubrid-loaddb.md, cubrid-compactdb.md, cubrid-backup-restore.md, cubrid-csql.md, cubrid-cub-admin.md, cubrid-unloaddb.md, cubrid-master-process.md, cubrid-checksumdb.md, cubrid-migrate.md, cubrid-loadjava.md, cubrid-utilities-misc.md).

The utilities surface is now fully covered. Bulk-data quartet (loaddb / unloaddb / compactdb / backup-restore), the user-facing entries (csql, cub-admin), the daemon (master-process), HA integrity (checksumdb), the version-locked 9.1→9.2 in-place upgrader (migrate), the JavaSP installer (loadjava), and an omnibus for the small standalone helpers (utilities-misc: commdb, gencat, generate_timezone, daemon, cubrid_version, pl bootstrap).

Open. None at subsystem granularity.

i18n and specialty features

Covered. (cubrid-overview-i18n-specialty.md, cubrid-charset-collation.md, cubrid-timezone.md).

Open. None at subsystem granularity. (The offline generate_timezone build tool lives in the utilities omnibus above, not here.)

Intentional non-goals

These will not get their own docs unless the constraint changes:

• dblink — explicitly skipped at user direction. Mentioned in cubrid-scan-manager.md (the S_DBLINK scan type) and cubrid-overview-query-processing.md, but no detail doc planned.
• Per-symbol coverage. This map is at subsystem granularity. We don’t track which functions/structs lack prose; the per-doc position-hint tables already pin canonical symbols.
• 3rdparty/, win/, demo/, msg/, locales/, debian/, .circleci/, .github/ — not part of the engine surface area.
• Unit-test executables (unittests_*.c under src/executables/) — coverage of the engine invariants those tests exercise belongs in the corresponding subsystem doc, not in a doc about the test harness.

How to grow this map

When a new doc lands:

1. Add it to the appropriate “Covered” line (alphabetical within the line).
2. Remove it from the matching “Open” entry.
3. Bump updated: here (and the KO mirror, per the bilingual rule).
4. Re-run /kb-index knowledge/code-analysis/cubrid to refresh README.md.

When a new subsystem appears in the source tree:

1. Decide its grouping — usually one of the eight subsections above.
2. Add an “Open” entry naming the source path and the planned doc slug.
3. Don’t promote it to “Covered” until the doc actually lands.

When a non-goal becomes a goal (e.g., dblink gets a doc):

1. Move the entry from “Intentional non-goals” into the matching subsection’s “Open” line, with a brief note on what changed.

Adjacent reading

• README.md — per-doc catalog (auto-generated).
• cubrid-architecture-overview.md — process model + layered stack + cross-refs into every detail doc.
• cubrid-design-philosophy.md — the thirteen architectural decisions that explain the codebase shape.
• knowledge/methodology/code-analysis-doc.md — the playbook these detail docs are written against.