← All digests

DBMS Weekly — 2026-08-24 (week of Aug 24–30)

The week's biggest PostgreSQL news is a subtraction: ALTER TABLE ... MERGE/SPLIT PARTITION(S), committed months ago for 19, got reverted wholesale — roughly 4,800 lines out, including its own isolation tests — after Zsolt Parragi's July bug report showed it could silently change generated- column values and drop rows out of logical replication. Elsewhere the tree had an unusually tight bug-to-fix week: a subscription-refresh crash found Sunday was committed Tuesday, an invalid-index bug in REPLICA IDENTITY FULL lookups from last week's digest landed this week, and Nathan Bossart spent one sitting finding eight distinct bugs in the three-week-old REPACK command by testing it against itself. AI showed up twice as a research tool rather than a research subject: Noah Misch credited "Opus 5" with finding a v19 ILIKE regression, and Hannu Krosing disclosed that his pgbench server-extension patch was "almost entirely generated by AI harness." Outside the tree, DuckDB's commercial arm DuckLabs is becoming an AWS subsidiary (DuckDB itself stays MIT), and Oracle's own SQL Plan Management team published a paper on foreground plan-regression verification the same week a Postgres user asked hackers why nothing watches pg_plan_advice for drift.

PostgreSQL

  • Revert of ALTER TABLE ... MERGE/SPLIT PARTITION(S) — the feature isn't just buggy at the edges, it's gone: 13 commits and roughly 4,800 lines (including its own isolation-test suite) reverted from REL_19_STABLE two months before GA. The reporting thread (bugs/hackers, July 23) showed MERGE PARTITIONS moving rows with plain heap inserts that logical decoding sees as inserts with no matching deletes, generated-column values silently changing across a merge, and no documented safe path to propagate a merge/split to a subscriber. Alexander Korotkov's commit message: "multiple design issues which are too late to address in this release cycle." (Alexander Korotkov · pgsql-committers)
  • The Sixth Execution — "prepared statements skip planning" is folklore, not mechanism: PARAM_FLAG_CONST means a bound custom plan is exactly as value-aware as a text query, so nothing changes for the first five executions; PostgreSQL only switches to a value-blind generic plan on the sixth, and that's the moment queries mysteriously get slower. Traced against plancache.c on PG18. (Christophe Pettus · thebuild.com)
  • All Your GUCs in a Row: log_line_prefix and log_timezone — the near-daily logging-GUC series continued through seven more parameters this week (listen_addresses, the log_checkpoints/log_autovacuum_min_duration trio, log_connections/log_disconnections/log_hostname, log_destination, log_directory/log_filename, log_rotation_*); this entry is the meatiest — why log_line_prefix is the only join key you have between your logs and everyone else's. (Christophe Pettus · thebuild.com)
  • New things for regular expressions in PostgreSQL (pg_tre and pg_re2) — benchmarked against 1.6M real EXPLAIN plans: an unindexed regex scan takes 40s, pg_trgm + ~ gets a rare pattern down to 1.6s, and the new pg_tre trigram index (via a %~~/tre_pattern operator) answers the same query in ~2.3s off a 21GB index built in about 7 hours — real numbers, not vendor claims, for two extensions most people haven't tried yet. (Hubert "depesz" Lubaczewski · depesz.com)
  • How to optimize when you can't do anything! — a 750GB/16-billion-row table, a date-range predicate with no supporting index, and GIST build time measured in days: the fix was negotiating down to a handful of partial indexes built concurrently for the query shapes that actually mattered, not the theoretically correct one. (Henrietta Dombrovskaya)
  • The Dump That Breaks Its Own Restore — pg_dump's own preamble pins search_path to '', so an AFTER INSERT trigger that references its own table unqualified fails on restore into an empty target with relation ... does not exist — even though there isn't a single colliding row. Verified against 18.6 with pasted output; --disable-triggers, deferred constraints, and session_replication_role = replica are the three levers, two of which have hidden costs. (Mikhail Shytsko · seedfa.st)
  • Read your writes: WAIT FOR in PostgreSQL 19 — the new WAIT FOR LSN statement blocks a standby session until replay catches up to a given LSN, giving read-your-writes without synchronous_commit = remote_apply's write-side tax. The gotcha the docs undersell: WAIT FOR compares raw LSN positions with no timeline awareness, so a success after a promotion can refer to WAL from the wrong timeline. (Gülçin Yıldırım Jelínek · ClickHouse) [unverified: PG19 still in beta, details may change before GA]
  • MongoDB on PostgreSQL: DocumentDB with pglayers-azure — running Azure's DocumentDB-on-Postgres gateway end to end from a plain container: the non-obvious failure is that documentdb_api.create_user() pre-hashes the password for scram-sha-256, but DocumentDB's check_password hook wants the plaintext to build its own SCRAM verifier, so the "obvious" path errors and you need a direct CREATE ROLE instead. (Ismaël Mejía)
  • PostgreSQL 18: 23x Faster Inserts With UUID V7 — switching a billions-of-rows, 12k-inserts/minute table from UUIDv1/v4 to v7 primary keys cut multi-row insert time by up to 23x, because time-ordered keys keep the B-tree's hot insert page in cache instead of scattering writes across the whole index. (Andrew Atkinson)
  • How fast should you patch production PostgreSQL? — the August 13 release fixed 28 CVEs in one day (vs. 7 for all of 2025), including a to_char() heap-buffer-overflow RCE (CVE-2026-14669, CVSS 8.8); the actionable point is picking a patch-latency SLA (days for RCE/public-exploit bugs, 1-2 weeks for other highs) before the next release forces the argument. (Umair Shahid · Stormatics)
  • pgwatch v6: Prometheus becomes a source, not just a sink — pgwatch can now scrape a Prometheus exporter directly as a first-class source alongside Postgres sources, so cluster-manager and node-exporter metrics (e.g. Patroni's twelve-metric preset) land in the same pipeline without running a second collector. (Pavlo Golub · Cybertec) [by maintainer]

Releases

  • PostGIS 3.7.0rc1 — release candidate ahead of PG19 GA.
    • a run of OSSFuzz-driven hardening fixes: malformed SRID prefixes, hostile GSERIALIZED bbox/varlena payloads, and a recursive NURBS-curve bounding-box calculation that could burn unbounded backend CPU on crafted WKT input
    • requires PostgreSQL 14–19rc1; GEOS 3.15+ needed for all features

PostgreSQL mailing lists

630 messages on pgsql-hackers in the window, 66 of them new threads.

  • [hackers] pg_upgrade silently truncates nextMultiOffset to 32 bits — the widening of MultiXactOffset to uint64 missed pg_upgrade's own control-data parser, which still reads the value with str2uint(); on a busy enough cluster the truncated offset would corrupt the upgrade. Filed and committed same day. (Masahiko Sawada · pgsql-hackers) [committed]
  • [hackers] Logical replication can lose an update after concurrent index invalidation — the apply worker caches whether its chosen index is the replica identity/PK (letting it stop at the first match) separately from the index OID; a concurrent REINDEX CONCURRENTLY or DROP INDEX CONCURRENTLY can flip that answer between the two reads, so the worker stops early on the wrong index and silently drops an update. (Mihail Nikalayeu · pgsql-hackers) [open]
  • [hackers] pg_rewind: file sync bypass and findLastCheckpoint boundary crash — a clean shutdown-then-promote leaves the target's WAL ending exactly at the new timeline's divergence point, which pg_rewind treats as "nothing to rewind" and exits before the file-sync phase — skipping the new timeline history file and any non-WAL-logged file changes (like postgresql.auto.conf). Fixing that exposed a second crash in findLastCheckpoint(). (Srinath Reddy Sadipiralla · pgsql-hackers) [patch posted]
  • [hackers] Open SSI correctness issues — a roundup thread bundling several live serializable-isolation bugs with reproducers into one reading queue, including a SnapshotDirty uniqueness check that can let a serializable transaction observe two rows with the same primary key. Filed alongside a concrete fix for one of them: a summarized transaction's predicate locks referencing an unset finishedBefore let a genuine serialization cycle commit without either side aborting. (Andrey Borodin · pgsql-hackers) [open] — companion patch: SSI: A patch for a serializability violation (Vaijayanti Bharadwaj) [patch posted]
  • [hackers] Wrong result from JSON constructor in a simple CASE — found while reviewing an unrelated patch: eval_const_expressions substitutes a CASE's constant test value into a JSON_OBJECT(...RETURNING text) constructor's own CaseTestExpr placeholder, so CASE 'x' WHEN JSON_OBJECT('a':'b' RETURNING text) THEN 1 ELSE 0 END returns 1 instead of 0. (Richard Guo · pgsql-hackers) [patch posted]
  • [hackers] REPACK (ANALYZE) within transaction block segfaults — Nathan Bossart spent one Aug 27 sitting stress-testing the three-week-old REPACK command against itself and filed eight distinct bugs: a segfault running REPACK (ANALYZE) inside a transaction block, REPACK (CONCURRENTLY) rewriting tables marked user_catalog_table, ONLY being silently ignored (now disallowed and committed), failures when the table owner lacks CONNECT, no check on the table AM, decoding-worker startup diverging from parallel.c, indefinite waits when the decoding worker fails to start, and failure when the replica-identity index is dropped mid-run. Bharath Rupireddy and Zsolt Parragi added two more (wrong error for materialized views; a missing warning when skipping foreign partitions) by Aug 29. (Nathan Bossart · pgsql-hackers) [several fixed this week]
  • [hackers] pg_get_*_ddl() needs a redesign — a post-commit review of pg_get_role_ddl() turns into a broader objection: why omit PASSWORD from a DDL-reconstruction function at all if the goal is a faithful dump, and does the whole pg_get_*_ddl() family need a shared redesign rather than one-off decisions per object type. (Noah Misch · pgsql-hackers) [open]
  • [hackers] Detecting plan drift: pg_plan_advice pins plans, nothing watches them — PG19's pg_plan_advice/pg_stash_advice let you pin and auto-apply a plan, but neither one notices when the pinned plan silently stops being the one you'd choose today — a plan regression that doesn't error, just quietly switches from an index scan to a seq scan. The author asks whether that "noticing" piece belongs closer to core. Timely alongside Oracle's own plan-management paper this week (see Commercial engines). (Manuel Reyes Bravo · pgsql-hackers) [open]
  • [hackers] aio: Async fsyncs for crash recovery and checkpointer — extends Andres Freund's AIO groundwork to fsyncs during crash recovery and checkpoints, capping concurrent in-flight fsyncs by both io_max_concurrency and the file-descriptor budget; open question is whether re-opening files by path in AIO workers is worth a PgAioTargetData size increase. (Nazir Bilal Yavuz · pgsql-hackers) [patch posted]
  • [hackers] Allow aggressive VACUUM to freeze without a cleanup lock — an anti-wraparound VACUUM stuck behind overlapping SELECT FOR UPDATE buffer pins can be blocked indefinitely from acquiring a cleanup lock, letting unfrozen-XID age climb toward the wraparound threshold with no progress at all — a 2011-vintage problem the author found rediscovered in a multi-day-long VACUUM FREEZE stall. (Jingtang Zhang · pgsql-hackers) [patch posted]
  • [hackers] EUC_* ILIKE index scan stopped matching seq scan in v19 — "Opus 5 found the $SUBJECT regression from commit 630706c 'Add pg_iswcased()'. That finding still holds at today's master." One of two v19 regressions Noah Misch posted the same evening (the other: an identifier-downcasing change under LATIN1) — both attributed directly to an LLM's testing rather than a human's. (Noah Misch · pgsql-hackers) [open]
  • [hackers] pgbench Common Library Extraction & Server Extension — extracts pgbench's random-distribution generators, domain permutations, and 64-bit hashing into a server-side extension so custom workloads can run the same logic on the server instead of round-tripping through the client. The author's own disclosure: "the code is almost entirely generated by AI harness," alongside a companion proposal to modularize pgbench's architecture more broadly. (Hannu Krosing · pgsql-hackers) [patch posted]
  • Also filed this week — Persist slot invalidations before publishing them (Bertrand Drouvot), a save-ordering bug where an inactive replication slot can be marked invalid in shared memory before the state file catches up; Confusing behaviour of UPDATE together with FOR UPDATE subquery (WGH), where a FOR UPDATE subquery can silently skip rows concurrently touched by a top-level UPDATE; a three-part semijoin-planning series from William Bernbaum (1, pushing IS NOT NULL restrictions into semijoin RHS uniqueification); and Concurrent DROP TABLESPACE can miss a shared dependency (Ayush Tiwari).

What landed (pgsql-committers)

CommitFest (open: PG20-2, #61)

  • Balance: queue totals as of Aug 31: 312 needs review · 29 waiting on author · 56 ready for committer · 68 committed · 23 moved · 1 rejected · 1 returned · 16 withdrawn — 506 total. (vs last week's 453: total +53, needs-review +20, ready-for-committer +2, committed +18, withdrawn +7.) The per-CF activity log's ~100-row cap again ate the early week — the earliest reachable row this run was Fri Aug 28 02:37, so Mon–Thu flow (Aug 24–27) is invisible and the queue-total delta above is the reliable number.
  • New this week (visible portion, Aug 28–31): pgbench Common Library Extraction & Server Extension (Hannu Krosing) — see mailing-list item above; also filed: the two pg_rewind bugs (Srinath Reddy Sadipiralla), Concurrent DROP TABLESPACE can miss a shared dependency (Ayush Tiwari), a hashbulkdelete() interrupt-check patch (Mostafa Nasr), and two Sehrope Sarkuni patches hardening Win32 error handling and SCRAM iteration parsing in libpq.
  • Closed (visible portion): committed — pg_plan_advice empty FOREIGN_JOIN sublist fix, GIN posting-tree leaf-vacuum delay-point restore, the exported-snapshot xmin handoff race, apply-worker partition-leaf-closing fix, autovacuum parameter auto-propagation, the jointree join-removal series, thread-safe stringToNode(); withdrawn — "alert clients when prepared statements are deallocated," "Allow tuple visibility checks without hint-bit maintenance" (created and withdrawn twice in the same week), and libpq: add portaddr.

Community pulse

  • Your executable is a SQLite database — a prototype ("SELF") that replaces ELF with an actual runnable SQLite file (file hello reports "SQLite 3.x database"; sqlite3 hello 'SELECT soname FROM ldd' works); the biggest database-adjacent HN thread of the week and the top r/programming crosspost too. (Hacker News · 563 pts, 109 comments; also r/programming · 483 pts, 77 comments)
  • Solving the 1+N Query Problem — Evan Czaplicki's Acadia project (subject of last week's "Rethinking Database Programming" thread) argues the ORM-driven N+1 problem is a language-design defect fixable by borrowing Datalog's guarantee that queries terminate in time polynomial to the data. Split across two platforms: quieter on HN this week, but the biggest r/programming database thread of the week. (Hacker News · 59 pts, 54 comments; r/programming · 128 pts, 94 comments)
  • I put a wire-protocol proxy in front of containerized Postgres 18 so idle databases shut down fully and cold-start in ~170ms — stock Postgres in a container behind a proxy that speaks the wire protocol, holds the connection during a cold start, and shuts the container down completely when idle. The comment thread is the useful part: "why not just use separate databases in one engine?" versus the tradeoffs (per-project extension/version isolation, blast radius, portability) the author actually made. (r/PostgreSQL · 47 pts, 21 comments)
  • Show HN: LatticeDB — like SQLite but for graph databases — a single-file embedded property-graph database (Zig) with native vector and full-text indexing alongside graph traversal. (Hacker News · 188 pts, 54 comments)
  • DuckLake was 41x faster than Iceberg for our Postgres CDC workload — 1M rows/100k updates: Iceberg copy-on-write took 269s against DuckLake's 6.6s. The top comment immediately calls the comparison unfair — 100k updates is squarely merge-on-read territory, not COW's regime — and the author is re-running the benchmark against Iceberg MoR as a result. (r/PostgreSQL · 37 pts, 5 comments) [unverified: benchmark comparison disputed in-thread, re-test pending]
  • BtrLog: Low-Latency Logging for Cloud Database Systems — an older (June) preprint resurfacing on both Lobsters and HN this week; cloud-DB commit-log latency work. (Hacker News · 19 pts, 1 comment; Lobsters)

Wider DBMS & distributed data

  • DuckLabs to join AWS, projects to remain open source — DuckDB's commercial entity becomes an AWS subsidiary (effective early September); DuckDB, DuckLake, and the rest stay MIT-licensed under the non-profit DuckDB Foundation, which gains a stakeholder advisory board. The single biggest DBMS-industry story of the week. (Mark Raasveldt, Hannes Mühleisen · DuckDB)
  • No Silver Bullet: Boosting GaussDB Performance on the 30TB TPC-H Workload — Huawei's distributed shared-nothing GaussDB beat the best published 30TB TPC-H result by 40% via a pipelined execution model, a faster inter-node shuffle over unified remote memory access, and cost-based cross-node Bloom filter streaming. VLDB paper, not a press release. (Zeyl, Lam, Larson et al. · Huawei, Aug 28) [paper]
  • Catalog Bullshit: 把数据库拆开，再租给你一张 PostgreSQL 表 — a sharp technical rebuttal to Snowflake's lakehouse-governance framing: an Iceberg catalog's only irreplaceable job is a single-row compare-and-swap on a metadata pointer, and most of the "independent Catalog" industry (Hive Metastore, Nessie, Polaris, Lakekeeper — the last one explicitly requiring PostgreSQL 15+ as its persistence backend) exists because early S3 couldn't do conditional writes. Now that S3 supports them, the argument is that Catalogs are becoming a billing layer for something object storage can do natively. (冯若航 (Ruohang Feng) · blog.vonng.com) [zh] (orig: "Catalog Bullshit：把数据库拆开，再租给你一张 PostgreSQL 表") — see International for language tagging note; listed here for topical grouping.

Commercial engines (SQL Server, Oracle, MySQL, …)

  • Real-time SQL Plan Management in Oracle — Oracle's own SPM team on why background-only plan-regression verification is too slow for autonomous cloud databases with limited customer control over automatic actions, and how Oracle 26ai's Real-Time SPM validates a new plan in the foreground during the query that triggered it, rather than waiting for a batch job. Direct counterpart to this week's pg_plan_advice plan-drift discussion on pgsql-hackers. (Chakkappen, Ziauddin, Su, Kunjibettu, Bayliss · Oracle, Aug 27) [paper]
  • A safe MySQL upgrade that wasn't so safe — adding an AUTO_INCREMENT column via ALTER TABLE on a replicated table can assign different IDs on source and replica (row order depends on storage engine and processing order); five of six dependent tables picked up the new IDs correctly during a later migration, one didn't, and the postmortem walks through exactly which replication binlog-format interaction let that happen. (blog.elis.cc)

Research & cutting edge

International (non-English sources)

  • Oracle → PostgreSQL without downtime: migrating a terabyte-scale banking database and where it broke — a phased CDC migration (Debezium/LogMiner into Kafka, shadow reads, domain-by-domain read cutover, then write cutover) for a bank's credit domain at 500–3000 RPS read / 50–300 write peak, zero downtime tolerated. The failure catalog is the value: bare Oracle NUMBER defaulting to numeric instead of bigint for IDs, VARCHAR2 byte-vs-character length semantics silently truncating Cyrillic text, DATE→date losing time-of-day and breaking payment-schedule ordering, and Oracle's '' = NULL equivalence causing data to fork into "empty string" and "NULL" once the app started writing to Postgres directly. (habr.com, Aug 26) [ru] (orig: «Oracle → PostgreSQL без даунтайма: как мы перевозили терабайт банковской базы и где всё ломалось»)
  • I got laughed at over a VIEW question — so I benchmarked MySQL 8.4 against PostgreSQL 17 — real methodology (Docker Compose, byte-identical seeded data, two warmups + seven measured runs, median of EXPLAIN ANALYZE): a simple wrapper view costs nothing in either engine (MySQL inlines via MERGE, Postgres rewrites before planning), but a single CAST inside a materialized daily aggregate view makes it roughly 13x more expensive. (habr.com, Aug 25) [ru] (orig: «Меня подняли на смех за ответ про VIEW. Я поднял MySQL 8.4 и PostgreSQL 17 и померил»)
  • xxhash for Postgres — fast lookups on text keys — de-duping scraped records by text key is slow, so the author wrote pg_xxhash, a small C extension exposing 64-bit xxhash as a bigint-friendly hash; the gotcha is that xxhash's unsigned 64-bit range doesn't fit Postgres's signed bigint without an explicit midpoint shift, and doing the hash client-side in Python was "unacceptably slow" compared to computing it in the extension. (habr.com, Aug 27) [ru] (orig: «xxhash для Postgres — быстрый поиск по текстовым ключам»)
  • Catalog Bullshit: taking apart a database and renting you back one PostgreSQL table — see Wider DBMS above for the full gist. (冯若航 (Ruohang Feng) · blog.vonng.com, Aug 28) [zh] (orig: «Catalog Bullshit：把数据库拆开，再租给你一张 PostgreSQL 表»)
  • Verified quiet this window: blog.dalibo.com [fr] — newest post Aug 18 (a newsletter announcement); publickey1.jp [ja] — in-window items were restatements of the DuckLabs/AWS and DuckDB v2.0 news already covered above, no incremental Postgres/DBMS content.

New sources added this week

  • acadia.engineering (Evan Czaplicki) — a Datalog-inspired relational query language project; two substantive posts in two consecutive weeks ("Rethinking Database Programming," "Solving the 1+N Query Problem"), each driving genuine cross-platform HN/Reddit debate. P3.

54 items · sources scanned: Planet PostgreSQL (browser, full window), postgresql.org news archive + events page, pgsql-hackers via the official archive (630 messages / 66 new threads, Aug 24–30), pgsql-committers via mail-archive (159 in-window messages / 62 unique commit threads), CommitFest #61 detail page + per-CF activity log (partial, Aug 28–31 visible), arXiv cs.DB (Aug 25–31 day-buckets; Aug 24 not independently re-verified), HN via Algolia API (8 keyword queries, points>10, full-week epoch window), Reddit seven-sub sweep via the read-only JSON API sorted by comment count, Lobsters /t/databases, DBA Stack Exchange via the API, Habr PostgreSQL hub [ru], blog.vonng.com [zh], blog.dalibo.com [fr], publickey1.jp [ja] · filtered out as marketing/ads or below-bar: ~13 (a SQL-IDE launch post, a conference-attendee-list recap, a vague "telemetry/digital twin" thought-leadership piece, a community-roundup post, a Kubernetes-operator vendor tutorial, a generic fillfactor-formula post, a personal-nostalgia post, a redundant second post from the same author on the same day, two informal patch-development diary posts, an off-topic HN thread that only superficially matched a SQL keyword, a vendor self-promotion stats post, and a DBA Stack Exchange question at −1 score).

Source notes: the Claude-in-Chrome browser pane (mcp__Claude_Browser__*) blocks old.reddit.com outright ("blocked by policy") — the Control_Chrome MCP server (real host Chrome) reached it fine via the same old.reddit.com/r/<sub>/top.json?t=week&limit=40 recipe as prior weeks; Control_Chrome also handled Lobsters, DBA Stack Exchange, and all non-English sources this run. The Claude-in-Chrome pane handled Planet PostgreSQL, postgresql.org (news + mailing lists via the /list/<name>/since/<ts>/ same-origin-fetch recipe), commitfest.postgresql.org, mail-archive, and arXiv without issue. CommitFest: the per-CF activity log's ~100-row cap again lost the front of the week (earliest visible row Fri 02:37); the queue-total delta is the trustworthy week-over-week number, as in every prior run. Mailing lists: the postgresql.org/list/pgsql-hackers/since/<ts>/ pages needed three separate since/ fetches to enumerate all seven days without gaps — a single since/ page's date coverage is not contiguous with the next one's start point, so missing an intermediate day (this run: Aug 26 and Aug 29 fell through on the first pass) is a real risk; always verify the resulting date set covers all seven days before treating the scan as complete. Non-English: [ru] was again the most productive language (Habr's PostgreSQL hub had roughly 20 in-window posts, several genuinely strong); [zh] blog.vonng.com had one exceptional non-Postgres-specific-but-PG-adjacent piece (Catalog Bullshit, which name-drops Lakekeeper's PostgreSQL 15+ persistence requirement); [fr] and [ja] verified quiet rather than unscanned. modb.pro [zh] was not attempted this run — carry over the mobile-site/XHR-endpoint idea from prior notes. No CFP opened in-window (no "CFP is now open" news post between Aug 24–30), and no conference enters the 24–30-day horizon this week (the next horizon window, Sep 23–29, is empty of currently-listed events; Postgres Summit US 2026 starts Sep 30, one day past this week's horizon, and will be the pick next week), so both conference sections are omitted. One item is marked [unverified] for a disputed benchmark methodology (DuckLake vs. Iceberg) and one for a beta-software behavior detail (WAIT FOR timeline semantics, explicitly caveated by its own author as subject to change before PG19 GA).