Segment 1: HiddenMerit Morning Post · Issue 109

Focus on Database Frontiers, Practical Insights for DBAs September 21, 2026 ｜ 5 Selected Global Breaking News

01｜Transwarp Lists on HKEX Today: China’s Databricks, GPU‑Native Database Sparks Architectural Revolution

Transwarp (06727.HK) listed on the Main Board of the Hong Kong Stock Exchange on September 21, with an offer price of HK$49 per share. On its first day of trading, it was included in the Stock Connect, achieving “listing and inclusion simultaneously.”

Key Data: Transwarp is one of China’s first companies focused on AI and big data infrastructure software R&D, and was named to the “2026 IDC China AI 50.” Its GPU‑Native Cognitive Database migrates the database architecture from CPU to GPU, achieving complete execution of all 99 TPC‑DS SF50 queries on GPU without CPU fallback, with overall performance improvement of approximately 10.5x and a peak single‑query speedup of 94x. After multi‑card interconnection, TPC‑DS 1TB benchmark performance reached 100x that of two CPUs.

DBA Perspective: Transwarp’s listing is a landmark event marking the transition of GPU‑native databases from “technical validation” to “capital market recognition.” For DBAs, this means the hardware foundation of databases is undergoing structural change — tuning dimensions will expand from CPU cores, memory, and disk I/O to GPU video memory management, parallel stream scheduling, and data residency strategies. The H‑share listing will provide more funding support for commercialising GPU databases.

02｜pg_partman Exposes High‑Risk Privilege Escalation Vulnerability (CVE-2026-61821, CVSS 8.5): Low‑Privilege Users Can Move Tables Without Authorisation

The PostgreSQL partition management extension pg_partman has been found to have a high‑risk vulnerability (CVE-2026-61821, CVSS 8.5), affecting versions before 5.5.0.

Vulnerability Details: drop_partition_id() and drop_partition_time() use part_config.retention_schema as the target for ALTER TABLE SET SCHEMA, accepting any non‑empty schema name. A role with partman_user access can choose a target schema for which that role lacks normal CREATE privileges, and the background worker process executes the move with the privileges of pg_partman_bgw.role — which defaults to a PostgreSQL superuser — thereby bypassing the authorization checks that a normal ALTER TABLE SET SCHEMA operation would enforce. This allows unauthorised movement of retained child tables between schemas. The vulnerability has been fixed in version 5.5.0.

DBA Perspective: pg_partman is one of the most commonly used partition management extensions in the PostgreSQL ecosystem. The core issue with this vulnerability is that the background worker process executes operations with superuser privileges, bypassing the caller’s permission boundaries — exactly the same pattern as last week’s PostGREShell vulnerability’s “assumption failure.” DBAs using pg_partman should immediately upgrade to 5.5.0 and review whether the pg_partman_bgw.role configuration is appropriate.

03｜OpenTenBase 5.0 Debuts at China International Software Expo: Oracle/PG Dual‑Mode Isolation Support

At the 28th China International Software Expo held in Zhengzhou from September 20‑22, the OpenTenBase open‑source database project, donated by Tencent Cloud to the OpenAtom Foundation, showcased its latest technical breakthroughs.

Core Updates:

OpenTenBase 5.0: Supports Oracle/PG dual‑mode isolation at the overall architecture level, helping products achieve long‑term development in both the PG ecosystem and the de‑Oracle ecosystem; the HTAP‑oriented data forwarding layer code and connection management refactoring significantly improve overall performance.
TXSQL 8.0.30: Introduces enterprise‑grade features including online second‑level column changes, parallel DDL, Undo‑based flashback queries, primary‑standby BP synchronisation, asynchronous large table deletion, transparent column compression, and column encryption.

DBA Perspective: OpenTenBase 5.0’s “Oracle/PG dual‑mode isolation” is an architectural choice worth watching — the same database kernel can simultaneously serve the PG ecosystem and the de‑Oracle ecosystem, giving DBAs more flexible selection space in Xinchuang migration. TXSQL 8.0.30’s “online second‑level column changes” and “flashback queries” directly address the critical needs of financial‑grade scenarios for online DDL and data recovery.

04｜Oracle September CSPU Exposes Multiple High‑Risk Vulnerabilities: DBMS_REDEFINITION Privilege Escalation, Net Services Denial of Service

Oracle’s September CSPU (released September 15) contains multiple high‑risk vulnerabilities targeting Database Server.

Core Vulnerabilities:

CVE-2026-83271 (CVSS 8.8): RDBMS component vulnerability. A low‑privilege attacker with Execute privileges on DBMS_REDEFINITION can exploit it over the network, leading to complete takeover of RDBMS. Affects versions 19.3‑19.32, 21.3‑21.23, and 23.4.0‑23.26.3.
CVE-2026-83348: RDBMS component vulnerability. A low‑privilege attacker with Create DB Link privileges can exploit it.
CVE-2026-83160: RDBMS component vulnerability. A low‑privilege attacker with Create Table privileges can exploit it. Affects only 23.4.0‑23.26.3.
CVE-2026-83349 (CVSS 7.5): Oracle Net Services component vulnerability. Unauthenticated attackers can cause complete denial of service of Net Services over the network.

DBA Perspective: Multiple vulnerabilities in this CSPU have extremely low attack barriers — DBMS_REDEFINITION, Create DB Link, and Create Table are all routinely granted privileges in database development. This means an ordinary application development account could become an attacker’s springboard. DBAs are advised to immediately review all accounts with these privileges and assess whether they are configured according to the principle of least privilege.

05｜PostgreSQL 19 Delayed by Two Months: 74 Commits Reverted, Core Features Withdrawn in Bulk

PostgreSQL 19’s beta testing has entered a period of密集 rollbacks. In just the nine days from September 8 to 16, the stable branch saw 6 concentrated rollbacks, cumulatively withdrawing 74 commits — exceeding the 71 new commits merged during the same period. The industry widely expects the official release to be delayed by approximately two months from the original plan.

Core Features Rolled Back:

Online data checksum switching (30 commits): fully withdrawn on September 16, retargeted for PG20
UPDATE/DELETE FOR PORTION OF (23 commits): reverted on September 15, temporal data processing capability postponed
System functions including pg_get_role_ddl() (13 commits): unexpectedly withdrawn on September 13
CREATE SCHEMA enhancements: reverted on September 11 due to compatibility issues
SQL/PGQ property graph queries (47 commits): reverted on September 7, with Tom Lane warning “if released we’ll find bugs we can’t fix”

The PostgreSQL core team is still targeting GA by the end of October, but delays are now certain. Snowflake noted in its analysis: “AI tools are helping find more bugs, and many reverts came from deep AI‑generated reviews.”

DBA Perspective: The PG 19 delay once again validates the PG community’s “quality first” principle. PG 18 LTS (supported until May 2031) is currently the more reliable upgrade target. The SQL/PGQ delay is particularly noteworthy — DBAs needing graph query capabilities should continue evaluating standalone graph databases or wait for PG20.

💡 SQL Little Knowledge Point

This Issue’s Knowledge Point: What is the “Background Worker Risk” of pg_partman?

pg_partman is the most commonly used partition management extension in the PostgreSQL ecosystem. One of its core designs is the background worker — responsible for automatically performing partition creation, deletion, and migration operations.

The Problem: The background worker runs with the privileges configured in pg_partman_bgw.role, which defaults to a PostgreSQL superuser. This means even if the caller has only low privileges, the background worker executes operations with superuser privileges.

Exploitation Logic of CVE-2026-61821:

The attacker has partman_user privileges
The attacker specifies a schema for which they lack CREATE privileges as the retention_schema
The background worker executes ALTER TABLE SET SCHEMA with superuser privileges, bypassing normal authorization checks
Result: retained child tables are moved to the attacker‑specified schema

Implications for DBAs: Any component that executes operations with “higher privileges” (background processes, schedulers, agents) requires independent privilege auditing. You cannot assume that “the operation is safe” simply because “the caller has low privileges.”

HiddenMerit Team Production Slogan: 绩优隐于内，金石启新程 | Hidden deep. Merit bold. Forge ahead.

Segment 2: HiddenMerit In‑Depth · Issue 22

Focus on Database Frontiers, In‑Depth Analysis September 21, 2026 ｜ 1 In‑Depth Feature Article

pg_partman Privilege Vulnerability Deep Dive: When Background Processes Become a “Superuser Backdoor”

1. Another “Privilege Assumption Failure”

Last week, the PostgreSQL ecosystem had just experienced the PostGREShell vulnerability (CVE-2026-6471) — a low‑privilege REPLICATION account could load malicious code through logical replication paths. Just days later, the pg_partman extension was found to have a privilege escalation vulnerability (CVE-2026-61821, CVSS 8.5).

The two vulnerabilities have different attack paths, but the core problem is identical: the system makes overly optimistic security assumptions about “low‑privilege accounts.”

PostGREShell assumed REPLICATION accounts wouldn’t abuse the replication protocol; pg_partman assumed users with partman_user privileges wouldn’t maliciously specify schemas. But security design cannot be built on the assumption that “users won’t abuse permissions.”

2. The Technical Essence of the pg_partman Vulnerability

pg_partman’s core function is automated partition table management — automatically creating new partitions based on time or ID, deleting expired partitions, and migrating retained partitions. To achieve automation, it introduced a background worker.

Privilege Model of the Background Worker:

Component	Role	Default Privileges
Caller	`partman_user`	Low privileges
Background Process	`pg_partman_bgw.role`	PostgreSQL Superuser

Exploitation Chain:

[quads id="805"]

Prerequisite: The attacker has partman_user privileges (typically granted to applications or operations tools).
Action: Call drop_partition_id() or drop_partition_time(), specifying a retention_schema in part_config that is a schema for which the attacker has no CREATE privileges.
Execution: The background worker executes ALTER TABLE SET SCHEMA with superuser privileges, moving retained child tables to the attacker‑specified schema.
Bypass: A normal ALTER TABLE SET SCHEMA would check the caller’s CREATE privileges, but the background process’s superuser identity bypasses this check.

Key Issue: The background worker’s privileges are “preset superuser,” not “the caller’s privileges.” This means any user who can trigger the background process is indirectly executing operations with superuser privileges.

3. Why Is “Background Process Superuser” a Dangerous Pattern?

pg_partman’s design is not unique. Many database automation tools adopt a similar pattern: background processes run with high privileges, executing operations on behalf of low‑privilege users. This pattern is functionally reasonable — automation requires sufficient privileges to perform DDL operations. But from a security standpoint, it introduces a fundamental problem: privilege boundary failure.

Traditional Privilege Model: User A executes an operation → the system checks whether A has privileges → execute if yes, reject if no.

pg_partman’s Model: User A triggers the background process → the background process executes the operation with superuser privileges → the system does not check A’s privileges.

This means: any user who can trigger the background process gains superuser execution capability — even if they themselves have only low privileges.

4. Emergency Action Checklist for DBAs

Priority 1: Upgrade pg_partman Immediately upgrade to 5.5.0 or higher.

Priority 2: Review Background Process Privilege Configuration Check the pg_partman_bgw.role configuration:

SHOW pg_partman_bgw.role;

If this role is a superuser (the default), assess whether it can be downgraded to a dedicated role with only the necessary DDL privileges rather than superuser.

Priority 3: Review partman_user Privilege Scope

SELECT rolname, rolsuper FROM pg_roles WHERE rolname LIKE '%partman%';

Identify which accounts have partman_user privileges and assess whether all of them need this privilege.

Priority 4: Review retention_schema Configuration

SELECT * FROM partman.part_config WHERE retention_schema IS NOT NULL;

Confirm that all configured retention_schema values are trusted schemas.

5. The Bigger Picture: “Privilege Inflation” in Automation Tools

The pg_partman vulnerability reveals a broader trend: “privilege inflation” in database automation tools.

Cause: Automation tools need to perform DDL operations (creating tables, dropping partitions, modifying schemas), which typically require high privileges. To “get automation running,” tools are granted superuser privileges.

Risk: When automation tools are controlled by attackers, superuser privileges become the attacker’s “backdoor.” Attackers don’t need to directly obtain the superuser password — they only need to trigger a background task running with superuser privileges.

Implications for DBAs:

Audit all automation components running with “high privileges” (background processes, schedulers, agents, MCP Servers).
Minimise automation component privileges — not “give it superuser and be done,” but “give it exactly the privileges it needs.”
Treat automation components as part of the “security boundary” — their privilege configuration is part of the security baseline, not part of “operational convenience.”

6. Security Concerns in the PostgreSQL Ecosystem

The consecutive emergence of the pg_partman vulnerability and the PostGREShell vulnerability points to a structural challenge in the PostgreSQL ecosystem: the lack of a unified standard for extension privilege models.

The PostgreSQL kernel has a mature privilege management system (roles, privileges, RLS, column‑level privileges), but extensions can freely define their own privilege models. pg_partman defined partman_user and pg_partman_bgw.role, but did not mandate that “background process privileges should inherit the caller’s privileges” or that “background processes should not use superuser.”

For DBAs, this means: every PostgreSQL extension requires independent security assessment. You cannot assume that “the PostgreSQL kernel is secure” equals “the entire database is secure.”