DB Weekly: Postgres 19 RC 1's upgrade traps, and PgBouncer's SCRAM bypass
The October 12-19 brief turns PostgreSQL 19's release candidate, PgBouncer's SCRAM impersonation fix, MongoDB's four-branch patch wave and a Postgres-to-ClickHouse reporting migration into concrete upgrade gates for backend teams.
The week from October 12, 2026 at 10:00 a.m. through October 19, 2026 at 10:00 a.m. (UTC-08:00) opened PostgreSQL 19's final stretch and closed a hole in the pooler that sits in front of most Postgres fleets. The PostgreSQL Global Development Group posted release candidate 1 on October 15 and named November 19 for general availability. 1
PgBouncer shipped 1.26.1 on October 14 with three CVEs, the first of which lets a client holding one SCRAM user's password log in as any other SCRAM user, administrators and backend superusers included. 2 MongoDB patched four server branches on October 14 and reclassified one aggregation stage's memory behaviour in the same wave. 3
Oracle published nothing for MySQL in the window. The announcements feed still ends at the August 25 release train, and the Oracle MySQL blog's newest release post is July's. 45 On the vector side, Weaviate patched its new GA line and Milvus published a tag, while Qdrant's newest release remains 1.19.2 from October 5 and pgvector's is 0.8.7 from October 1. 67
Decision table
| Date (UTC-08:00) | Component | Verified change | Trade-off or gate | Immediate check |
|---|---|---|---|---|
| Oct 15 | PostgreSQL 19 RC 1 | Release candidate 1; RC 2 arrives November 12 alongside the quarterly update release, GA on November 19; fixes since Beta 4 cover REPACK (CONCURRENTLY), pg_plan_advice, NULL-aware planner work, automatic logical-replication enablement and parallel autovacuum 18 | JIT defaults to off in 19; max_locks_per_transaction doubles to 128 with a changed lock allocation; pg_upgrade refuses clusters with btree_gist inet or cidr indexes | Run an upgrade dry run now, then repeat it on RC 2 |
| Oct 14 | PgBouncer 1.26.1 | Fixes CVE-2026-107350 (SCRAM impersonation, versions 1.17.0 through 1.26.0), CVE-2026-107349 (empty option name, 1.20.0 through 1.26.0) and CVE-2026-107348 (packet length overflow, 1.21.0 through 1.26.0); ignore_startup_parameters now outranks tracked parameters 9 | The fix ships only in 1.26.1, which carries 1.26.0's parameter tracking with it; search_path tracking bugs remain open | Patch every pooler that authenticates SCRAM users |
| Oct 14 | MongoDB 9.0.4, 8.3.13, 8.0.34, 7.0.45 | 9.0.4 repairs three resharding deadlocks and hangs, a heap-use-after-free in $_internalApplyOplogUpdate, and count with limit 0 on views; adds Ubuntu 26.04 support 3 | The same release marks $graphLookup as a stage that writes temporary data, inside 9.0's per-operation memory limit | Re-run the $graphLookup jobs that approach the ceiling |
| Oct 14 | PyMongo 4.19 | Drops Python 3.9, Python 3.10 and PyPy; adds Python 3.15 support, KMS access through an HTTP proxy, and srv_host_validator 10 | A minor version that raises the interpreter floor | Pin 4.18.x wherever 3.9 or 3.10 is in service |
| Oct 12 | Weaviate v1.40.1 | First patch on the 1.40 GA line: stops schema code dropping a live class that differs from an orphan only by letter case, pins zlib for CVE-2026-85091 and golang.org/x/net for CVE-2026-78663, repairs queue replay, backup buffering and shard unloading 11 | 1.40.0 shipped on October 7 without those repairs | Anyone who moved to 1.40.0 last week runs 1.40.1 |
| Oct 13 | Milvus v3.0.3 | Tag published with the note "Release note is coming..." 12 | A downloadable binary with no verifiable change list | Hold upgrades until the note lands |
| Oct 14 | psqlODBC 18.00.0005 | CVE-2026-109448, CVSS 5.9: a signed 16-bit parameter counter overflowed past 32,767 bound parameters; SQLBindParameter now rejects parameter numbers above 32,767 with SQLSTATE 07009 13 | Statements built as long IN (?, ?, ...) lists from user input are the exposed shape | Audit how many parameters your application binds |
| Oct 18 | pgBackRest 2.60.0 | Restore now stops on an invalid page checksum and must be rerun; expire refuses when the oldest retained backup would hold checksum errors; checksum-page-error=n warns instead 14 | Restore automation that quietly tolerated a damaged backup now fails loudly | Test one restore per repository before upgrading |
| Oct 14 | Ridgeline, Postgres to ClickHouse Cloud | A 10 to 40 times jump in customer data volume pushed inception-to-date reporting off Postgres; report batches fell from hours to minutes and the customer count more than doubled 15 | History went to Iceberg at a stated 40 ms connector cost per query; transactional data stayed on Postgres | A template for offloading analytical reads |
| Oct 14 | ClickHouse CostBench against Redshift Serverless | 113.2 billion quotes streamed at a target of one million rows per second: $28.69 against $522.03 in preparation cost, 58.12 seconds against 6,093.54 seconds of accumulated query runtime, a 1,996 times end-to-end lead 16 | The priced Redshift writer is a 32-RPU model; the measured long run used 128 RPU | Use it to price the preparation path for settled data |
| Oct 16 | Percona XtraDB Cluster on large folios | A move from PXC 5.7 to 8.0 onto Debian 12 and kernel 6.1 produced periodic multi-gigabyte write bursts, 61% of one burst charged to Galera applier threads 17 | mmap-based gcache files on a kernel with large folios amplify small status writes | Check for bursts about every 33 seconds and rising FilePmdMapped |
PostgreSQL 19 RC 1, and the list that decides your upgrade window
A release candidate is as close to the shipped version as the project can get, and this one comes with dates at both ends. The announcement describes RC 1 as "mostly identical to the initial release". 1
The calendar carries the useful detail. RC 2 lands on November 12, the same day as the quarterly update release for supported branches, because the release team decided to fold that batch of fixes into 19 before it ships rather than after. General availability follows on November 19. 1
For anyone booking time, that splits the work in two. A test cycle that starts on RC 1 today will be re-run on a build that also carries the November update release four weeks later, so the RC 1 pass is about finding your own incompatibilities early, and RC 2 is the build that predicts production.
What changed since Beta 4 is mostly repair in the features this release adds. The list names several fixes each to
REPACK (CONCURRENTLY), pg_plan_advice, the new planner optimizations that depend on whether an expression can be null, and the automatic enablement of logical replication when wal_level is replica. Parallel autovacuum took several more. Two changes are narrower and worth knowing because they alter observable output: postgres_fdw statistics import now runs as the owner of the foreign table instead of the user running ANALYZE, and COPY (query) TO ... (FORMAT json) now uses the query's column names and aliases as JSON keys instead of the table's. 1The incompatibility list is where upgrade projects get their scope. Three entries change behaviour for workloads that already work today.
JIT compilation is disabled by default in 19. Sites running many large analytical queries have to enable it themselves, and a reporting workload moved to 19 with default settings will run those queries without JIT until someone notices. 8
max_locks_per_transaction moves from 64 to 128, and the way lock sizes are allocated changed with it, so matching a previous capacity means roughly doubling the configured value again. A partitioned schema that was tuned against 64 will behave differently after the upgrade. 8pg_upgrade now refuses two cluster shapes outright: databases, roles or tablespaces whose names contain carriage returns or line feeds, and clusters carrying the broken btree_gist opclasses for inet and cidr. The default opclasses for those types move to GiST, and the old btree_gist versions are unsafe because they can exclude rows from results. 8Two more entries matter for pipelines and dashboards.
standard_conforming_strings is forced on inside the server, so a dump made with it off will not load, and the dump has to come from a 19-era pg_dump. The wait event type BUFFERPIN is renamed to BUFFER, which quietly breaks any monitoring query that filters on the old string. 8Authentication carries its own small set of deadlines. MD5 password authentication now emits a warning after a successful login, controllable through
md5_password_warnings, and RADIUS support is gone because PostgreSQL only ever supported RADIUS over UDP. 8The ecosystem is tracking the candidate. pgBackRest states that 2.59.2 and later support 19rc1, and its newest release arrived on October 18. 14 pg_hint_plan published 1.9.0 with PostgreSQL 19 compatibility on October 18. 18
PgBouncer 1.26.1: one password, any account
The changelog names this release "Only startup once", and the title describes the bug it fixes. Between versions 1.17.0 and 1.26.0, PgBouncer processed a second
StartupMessage sent during SCRAM authentication when the client connected to a database that does not exist. An attacker who knows the password of one user listed in auth_file could use that second startup message to log in as any other user that authenticates with SCRAM. 9The conditions are specific and common. SCRAM, the salted challenge-response password method PostgreSQL uses, has to be the method for both the attacker's account and the target account, and the impersonated user can come from either
auth_file or auth_query. Administrators and backend superusers are in range. 9Two denial-of-service bugs ship in the same release, both reachable without authentication. CVE-2026-107349 spins PgBouncer on a CPU core forever when a client sends a startup
options parameter with an empty option name such as -c=, which is only exploitable when ignore_startup_parameters is non-empty and does not contain options. CVE-2026-107348 hangs the process on an integer overflow in buffer growth when a client declares a packet length above 2^31, reachable only with max_packet_size set to 2,147,483,649 or higher, and reachable before authentication since 1.23.0. 9Because PgBouncer is single-threaded, a hang in either bug stops every client and every database the process serves. The second is the same class of flaw as CVE-2026-6668, fixed in 1.26.0, in a different buffer implementation. 9
The upgrade decision is made for you by the version ranges. The impersonation flaw runs from 1.17.0 through 1.26.0, so the 1.25 line is affected too and there is no older release to retreat to. 1.26.1 is the only fixed version. 9
That matters because 1.26.0 changed how the pooler treats session parameters, and 1.26.1 only partly settles it. Since 1.26.0, PgBouncer tracks every parameter PostgreSQL reports, which on PostgreSQL 18 and above includes
search_path and on 14 and above includes default_transaction_read_only. A configuration that relied on ignore_startup_parameters = search_path silently stopped ignoring it. 1.26.1 makes ignore_startup_parameters take precedence, so that line restores the 1.25 behaviour of ignoring search_path. 9The changelog is explicit that this is a patch over a rough edge rather than a completed repair. It notes that various bugs were reported around tracking of
search_path and that those will be addressed in a later release. 9 Fleets that enabled tracking on purpose, or that serve Citus or PostgreSQL 18 behind the pooler, should treat 1.26.x as a version to watch rather than a version to forget.MongoDB: four branches patched, and what $graphLookup now costs
MongoDB published 9.0.4 on the morning of October 14, alongside patches for the 8.3, 8.0 and 7.0 lines. The announcement describes 9.0.4 as fixes only since 9.0.2 and a recommended upgrade for all 9.0 users. 3
Three of the fixes sit in resharding, where they matter for anyone who runs the operation on a busy cluster. One closes a recipient-service deadlock on a rapid stepdown followed by a stepup, another prevents a stepup hanging when a stale in-memory chunk operation blocks recovery of a persisted recipient, and a third removes a deadlock between resharding initialization, chunk migration commit and
setFCV. 3Two more are correctness bugs in queries. A heap-use-after-free in the
$_internalApplyOplogUpdate stage appeared when results were read through getMore after the aggregate invocation had been destroyed, and count with limit 0 failed on a view while working on a collection. Constant values in a $bucket stage were being serialized incorrectly. 3The change with the longest reach is a classification change. The ticket listed as SERVER-130431 is titled "Mark
$graphLookup as DiskUseRequirement::kWritesTmpData". That flag is how the server decides which aggregation stages may write temporary files rather than staying inside memory. 3Pair it with 9.0's per-operation memory limit, which caps a single query operation at 1 GB or 20 percent of the server process's available memory, whichever is greater, and is configured through
internalQueryMaxMemoryUsageBytesPerOperation. An operation that exceeds the limit fails with ExceededMemoryLimit (error code 146) or, when disk use is not allowed, QueryExceededMemoryLimitNoDiskUseAllowed (code 292). 19So a
$graphLookup that outgrows the ceiling is now a stage expected to write temporary files, and whether it survives depends on the allowDiskUse setting on that workload. Teams that moved to 9.0 and left graph traversals at their previous settings should rerun the largest ones and watch for error code 292.The interpreter floor moves in the Python driver. PyMongo 4.19 drops support for Python 3.9 and 3.10 and removes PyPy entirely, while adding Python 3.15. 10
Most of the rest of 4.19 is field-encryption work. Key Management Service requests can now route through an HTTP proxy with a
kms_connect_callback or the built-in proxy helpers, so the driver performs the KMS TLS handshake over the proxy and still verifies against the KMS host. A new srv_host_validator callback accepts or rejects each host returned by SRV lookup, an alternative to srvAllowedHostsSuffix. 10Vector engines: Weaviate patches its new GA line, Milvus ships a tag without a note
Weaviate published v1.40.1 on October 12, five days after 1.40.0 reached general availability. The release lists no breaking changes and no new features, and one fix in it completes a repair that the previous issue watched land on the older branches. 11
That fix stops a schema bug from dropping a live class that differs from an orphaned class only by letter case. The same repair landed in v1.39.12 and v1.38.21 minutes before the previous window closed, and 1.40.0 had shipped without it. A team that took the GA tag on October 7 inherited the bug. 1120
The rest of the tag is operational repair plus two dependency pins. The queue replays a failed batch on its next turn instead of blocking workers, and recovers unreadable or corrupt chunks without leaving them counted. Backup objects are read into one buffer sized from the object length, incremental backups decode only what they read, and role assignments now travel with a user snapshot. Dedupe checkpoint planning fans out across classes and expires abandoned checkpoints. Several paths that could load a shard an unload had already released were closed in drop-vector, schema update, metrics and backup resume. zlib is pinned for CVE-2026-85091 and
golang.org/x/net for CVE-2026-78663. 11Milvus published v3.0.3 on October 13, and the tag carries no content beyond that it exists. The release body reads "Release note is coming...". 12 The previous Milvus tag, v3.0.2 on September 20, shipped a long list of search-path performance work and stability fixes, so a patch on the same line is worth having; without a note there is no way to say what it changes. 21
Two client and tooling changes that alter behaviour
psqlODBC 18.00.0005 fixes CVE-2026-109448, scored 5.9 by CVSS 3.1 and affecting versions 08.01.0102 through 18.00.0004. The driver stored the number of bound parameters on a statement in a signed 16-bit field. An application that bound more than 32,767 parameters wrote zeros outside the memory holding the bindings and could crash or continue with corrupted memory. 13
The fix is also a ceiling.
SQLBindParameter now rejects parameter numbers above 32,767 with SQLSTATE 07009, because ODBC reports parameter counts through 16-bit values. The release notes argue this breaks no working application, since no earlier release could execute a statement with more parameters. The exposed application shape is the one that builds an IN (?, ?, ...) list from user input; the suggested alternative is passing a value list as a single array parameter. 13pgBackRest 2.60.0 on October 18 changes what a restore does when it meets damaged data. Restore now errors and stops if any restored file contains an invalid page checksum, which leaves the cluster incomplete and unable to start until the restore is rerun.
expire refuses to run when the oldest retained backup would contain checksum errors, and that refusal also blocks archive expiry in that repository. Setting checksum-page-error=n downgrades both to warnings. 14The rest of the release is throughput and reach: prefetching multi-file and range reads from object stores, fewer keep-alive requests to remote processes, retries for Azure batch sub-requests missing from a response, GCS Workload Identity Federation, and builds against OpenSSL 4. 14
A named migration with a stated outcome: Ridgeline moves its analytics off Postgres
Ridgeline sells an all-in-one investment-management platform and describes itself as primarily a Postgres shop. Postgres kept the accounting and trade data and still does. What it could not keep was the performance-reporting workload, which derives daily profit-and-loss figures for every portfolio at 40 to 80 columns per portfolio per day. 15
The wall came with an upmarket push. A customer class roughly ten times larger than anything Ridgeline had onboarded before asked for inception-to-date reports at daily granularity across thousands of portfolios, which the shared Postgres cluster could serve only by consuming the whole cluster for a single report or by running out of memory. The incoming cohort represented a 10 to 40 times increase in volume. 15
Ridgeline evaluated Redshift, Trino over Iceberg, SingleStore, plugins that push Postgres toward columnar behaviour, and a calculation engine written from scratch in memory. ClickHouse won on performance and priced below the other analytical stores it compared. The choice of ClickHouse Cloud over self-hosting turned on security: as a financial-services company under SOC 2, Ridgeline was unwilling to give a third party a footprint inside its own VPC. 15
The architecture that resulted separates three data paths. Accounting data generated inside Ridgeline is written straight into ClickHouse. Vendor data such as custodian feeds and pricing lands transactionally in Postgres and replicates through ClickPipes CDC. Customer history arrives in bulk through a Spark pipeline into Iceberg, where decades of rows are cheaper to hold, and adapters pull that history into ClickHouse on demand. 15
The measured outcome is business-scale rather than query-level. Report batches that once ran for hours now complete in minutes, a change made in one part of the system propagates through the pipeline and materialized views in about a minute, and Ridgeline has more than doubled the number of customers live on the platform while moving upmarket. 15
The trade-offs are stated in the piece. Recent data, hundreds of gigabytes per tenant covering two to four years, lives in ClickHouse; older history stays in Iceberg and is read through the connector at what the team describes as a 40-millisecond hit. Queries over decades of data pay that cost. Transactional consistency for vendor data still depends on Postgres, and the two systems have to be kept in sync. 15
Read this as a case study published by the destination vendor, with qualitative outcomes and no per-query benchmark. The pattern it documents is the useful part: settled analytical history leaves the transactional database, and the operational price is a second system, a connector, and a synchronization path to own.
What the numbers show
ClickHouse against Redshift Serverless, with a modelling caveat. ClickHouse published the fifth part of its CostBench series, its own cost-and-performance benchmark, on October 14, streaming 113.2 billion stock-market quotes at a target of one million rows per second while four aggregate queries ran every ten minutes and two drill-downs every hour. Preparation cost came to $28.69 against $522.03, normalized query cost to about $0.05 against $24.97, and accumulated query runtime to 58.12 seconds against 6,093.54 seconds. Combined, that produces a 1,996 times end-to-end advantage per dollar. 16
Three disclosures change how far the figure travels. Redshift Serverless bills its compute in RPUs, its own capacity units, and the priced writer here is a 32-RPU model while the measured long run used 128 RPU; 32 RPU sustained the target in later characterization and 16 fell behind. The two systems also finished the ingest at different rates, with Redshift averaging 999,933 rows per second over about 31.45 hours and ClickHouse reaching roughly 0.86 million rows per second. And the freshness comparison shows Redshift's daily materialized view trailing the Kafka event watermark by 46 seconds at the median, 53 seconds at p95 and 79 seconds at its maximum. 16
The benchmark code and cost inputs sit in an open repository, so the model can be checked. Read the number as the price of keeping incoming data query-ready, which is the part of a real-time stack that vendor comparisons usually skip.
JavaScript inside MySQL, measured. Percona's Marco Tusa published the conference material behind
component_js_lang, the V8-based JavaScript routine layer for Percona Server for MySQL 8.4, on October 15. The demos carry timings. 22An iterative geometric-median calculation, the Weiszfeld procedure, took 11.00 seconds and 327,033 statements in procedural SQL against 0.52 seconds and six statements in JavaScript. Customer deduplication using Levenshtein distance found 21.7 percent of duplicates on name equality alone, and about 80 percent at 99.7 percent precision once SQL narrowed six million candidate pairs to 21,352 and the JavaScript function scored those. Input validation flagged 460 of 2,000 rows with a per-row list of faults, and a JSON-key normalizer turned a 51-line report into 19 lines. 22
The scope is a set of demos on one MySQL fork. The gain in the commute demo comes from avoiding 327,033 executor round trips, and the language itself does little of the work. One licence detail matters for planning:
session.runSql() today runs on MySQL Enterprise, and SQL executed from JavaScript is the top roadmap item for Percona Server. 22Galera cache writes on a newer kernel. Percona's Przemysław Malkowski published a customer case on October 16 in which a PXC upgrade from 5.7 to 8.0, run alongside a move from Debian 11 to Debian 12, produced regular bursts of multi-gigabyte writes from
mysqld while InnoDB write activity stayed flat. 17One burst, lasting a few seconds, divided by thread group:
| Thread group | Writes charged | Share |
|---|---|---|
| Galera write-set appliers | 13.0 GB | 61% |
galera_recv-0 receiver | 5.2 GB | 24% |
| InnoDB page cleaners | 2.0 GB | 9% |
| InnoDB redo log writer | 0.76 GB | 4% |
| Galera service thread | 0.29 GB | 1% |
The cause sits below MySQL. Galera's write-set cache is an
mmap-ed file, and kernels from 5.18 (XFS) or 6.16 (ext4) group page cache into large folios. The per-block dirty tracking added in 6.6 covers the write() path; an mmap write marks a whole folio dirty, so flushing one small status update can sync up to two megabytes. The burst period of roughly 33 seconds matches the default writeback timers of 5 seconds and 30 seconds. 17The workarounds in the post are filesystem and kernel choices rather than an application fix: EXT4 on kernels where folio support arrived later, a lower
read_ahead_kb, MADV_RANDOM hints on the mapping, a move to pwrite() on 6.6 and later, or a kernel compiled without transparent huge pages. The EXT4 route resolved this customer's case. Percona has the report open as PXC-5340. 17Evidence boundaries
No PostgreSQL core or supported-branch update release fell inside the window. The news archive's only project release is RC 1, and the next scheduled update release is November 12. 23 Oracle shipped no MySQL server or component release, so MySQL coverage here rests on Percona's engineering posts and describes builds downstream of Oracle's code. 4
Milvus's v3.0.3 carries no release note, so its content stays unverified rather than summarised from the tag. 12 Qdrant and pgvector published nothing in the window. 67
A matched benchmark placing separate database engines on shared hardware is still absent. ClickHouse's CostBench compares an analytical engine with a serverless warehouse, Percona's numbers compare index and language paths inside MySQL, and this brief's four families were not measured against each other by anyone this week. 1622
The CMU Database Group series ran no talk inside the window; the next one, Thomas Kejser on FloeScan, is scheduled for 4:30 p.m. Eastern on October 19, after this window closes. 24
Hacker News carried one database benchmark in the window, a Show HN post for KiviDB, a Redis-compatible in-memory store with a vector cache, claiming 21.2 million pipelined GET operations per second against Dragonfly's 9.1 million and Redis 8.10's 2.4 million on two matched hosts. It is the submitter's own measurement of an engine outside this brief's families, so it stays unpriced here. 25
Two items carry a date caveat. PostgreSQL 19's release notes page is marked as of October 9, which makes its incompatibility list a snapshot from before RC 1 shipped. 8 ClickHouse's Query Insights post announcing Postgres wait-event breakdowns carries an October 19 date with no publication time, so it cannot be placed inside the window with confidence.
Cross-engine positioning
The pooler has become the most exposed authentication surface in a Postgres deployment. PgBouncer's SCRAM exchange, the piece that lets a fleet avoid handing database passwords to every application, was a path from one known password to any account in every release from 1.17.0 through 1.26.0. 9 Teams that terminate authentication at the pooler now have one credential failure that spreads to the whole fleet.
PostgreSQL 19 changes defaults that existing operations depend on. JIT off by default, the lock-table sizing change, the
BUFFERPIN rename and the dump-format rule for standard_conforming_strings all touch settings teams configured years ago and stopped reading. 8 Migration planning for 19 is monitoring and dump planning as much as query planning.ClickHouse spent the week arguing that settled data should leave the transactional database. The Ridgeline case shows a reporting tier moving off Postgres. A separate engineering post on October 15 puts a unit-economics case for the same pattern: columnar storage compressing 10 to 30 times, infrastructure at roughly a fifth of the cost, and aggregations costing about 100 times less. The same post names the price of that trade, with single-row reads taking hundreds of milliseconds and reads that may see values about a second old. 1526 Both come from the vendor selling the destination, and the ratios are its own.
The vector engines are in a patch-and-pin phase. Weaviate has shipped a repair release on its GA line and on its previous branches in each of the last two weeks, and the newest one carries explicit dependency pins for published CVEs. 11 Milvus ships tags ahead of notes, which leaves operators choosing between an unexplained binary and an older one. 12
Action queue
- Move every PgBouncer that authenticates SCRAM users to 1.26.1 today. Treat pools reachable from untrusted networks as urgent, and check
ignore_startup_parametersforsearch_pathonce the upgrade is in. 9 - Audit applications that build parameter lists from user input before touching the ODBC driver, then upgrade psqlODBC to 18.00.0005. 13
- On MongoDB 9.0, move to 9.0.4 if resharding is part of your operations, and rerun the largest
$graphLookupaggregations against the memory limit withallowDiskUseset deliberately. 319 - Pin PyMongo to 4.18.x on any service still running Python 3.9 or 3.10, and schedule the interpreter move separately from the driver move. 10
- Take Weaviate 1.40.1 if 1.40.0 is already running, and check whether your schema history contains classes differing only by letter case. 11
- Run a PostgreSQL 19 upgrade dry run against a copy now, including
pg_upgradeagainst anybtree_gistinet or cidr index and a dump reload withstandard_conforming_stringson. Repeat the whole pass on RC 2 on November 12. 8 - Before upgrading pgBackRest, decide whether restore should stop or warn on a bad page checksum, set
checksum-page-error=nif you want the old warning behaviour, then test one restore per repository. 14 - On any Galera or PXC cluster running a kernel with large folios, check
FilePmdMappedand iostat for bursts near 33 seconds before blaming the workload. 17
References
- 1PostgreSQL 19 RC 1 Released!
postgresql.org
- 2PgBouncer 1.26.1 released - Fixes three CVEs
postgresql.org
- 3MongoDB 9.0.4 is released
mongodb.com
- 4MySQL Forums - Announcements
forums.mysql.com
- 5The Oracle MySQL Blog
blogs.oracle.com
- 6Releases: qdrant/qdrant
github.com
- 7pgvector CHANGELOG
github.com
- 8PostgreSQL 19 release notes
postgresql.org
- 9PgBouncer changelog
pgbouncer.org
- 10PyMongo 4.19 Released
mongodb.com
- 11Release v1.40.1
github.com
- 12Release v3.0.3
github.com
- 13psqlODBC 18.00.0005 released
postgresql.org
- 14pgBackRest 2.60.0 Released
postgresql.org
- 15How Ridgeline unified Iceberg and ClickHouse
clickhouse.com
- 16Why Redshift Serverless can't match ClickHouse Cloud
clickhouse.com
- 17When a Small Change Writes Too Much
percona.com
- 18pg_hint_plan v1.9.0 Released
postgresql.org
- 19MongoDB 9.0 release notes
mongodb.com
- 20Release v1.39.12
github.com
- 21Releases: milvus-io/milvus
github.com
- 22JavaScript in MySQL: Extending SQL
percona.com
- 23PostgreSQL: News Archive
postgresql.org
- 24Whatever Andy Found Interesting While Out At Sea
db.cs.cmu.edu
- 25Show HN: KiviDB
news.ycombinator.com
- 26OLTP is expensive, you can ClickHouse it
clickhouse.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.