Latest Blog Posts

Zero-downtime Postgres upgrades with logical replication
Posted by Dimitri Fontaine on 2026-10-13 at 12:14

This is part 3 of a series about Postgres logical replication use-cases, and about how the feature set has evolved over the past ten years and ten releases (Postgres 10 through the Postgres 19 beta), one architecture at a time. Part 1 built a hub-and-workers system for write scalability and has the table of what each release added, which this post assumes. Part 2 consolidated several application databases into one warehouse. This one is the most common reason to touch logical replication at all: a major-version upgrade with no downtime, and a way back if it goes wrong.

Making COUNTs and the Rest of Search Really Fast (Part II)
Posted by Ming Ying in ParadeDB on 2026-10-13 at 12:00
How ctid-aware segment partitioning, an inverted DocId map, and bitmap postings accelerated ParadeDB's Wikipedia COUNT queries—then a look at the rest of search, where ParadeDB delivered 10–22x TIN's throughput on filtered and time-sorted Hacker News queries.

Conference Preview: EDB at PGConf.Asia 2026
Posted by Floor Drees in EDB on 2026-10-13 at 08:36

PGConf Asia 2026 is heading to Hong Kong from November 17–18! As a premier regional event for the PostgreSQL community, PGConf.Asia brings together developers, contributors, DBAs, and enterprise users from across the continent. Several EDB team members will be presenting sessions this year. Additionally, EDB's own Bruce Momjian is serving on the organizing committee and co-chairing the program committee. Here is a sneak peek at the EDB-led sessions at PGConf Asia:

Strategic insights

What's Missing in Postgres? - Bruce Momjian (Keynote)

While Postgres introduces roughly 200 features and

CUDA and PostgreSQL: Twins from two Worlds
Posted by Abhisek Goswami in Cybertec on 2026-10-13 at 03:00

Do you know about the Winklevoss twins, Cameron and Tyler? They grew up together, went to the same university, and eventually built very different things around technology, finance, and entrepreneurship. Whatever you think of their story, there is something fascinating about twins who start from the same place and then take their abilities into different directions.

Now imagine two twins who grow up in completely different families.

One becomes obsessed with organizing information, while the other becomes obsessed with doing enormous amounts of work at the same time.

They spend years in completely different worlds. Then one day, they meet. And someone says:

“You two might actually work really well together.”

That is the story I want to tell about PostgreSQL and CUDA.

They are not really twins, of course. They were born almost a decade apart, built for different purposes, and live at very different levels of the computing stack.

But there is an uncanny similarity in one of the ideas behind them. 

Let me explain.

Two births, roughly a decade apart

PostgreSQL's story goes back to the POSTGRES project at the University of California, Berkeley. In 1996, the project moved from the name Postgres95 to PostgreSQL, starting with version 6.0.

Then, roughly ten years later, another important piece of the computing world arrived.

In 2006, NVIDIA introduced CUDA, giving developers a programming model for using GPUs for general-purpose computation.

Two technologies with very different beginnings. Relational databases like PostgreSQL have been dealing with something, humans have been struggling with forever:

How do you keep information organized and reliable when lots of people are using it at the same time?

CUDA came from a very different question:

What if we could use the enormous number of computing resources inside a GPU for things other than drawing pixels?

Different questions with different answers.

But there is a common idea hiding underneath both.

[...]

All Your GUCs in a Row: port
Posted by Christophe Pettus in pgExperts on 2026-10-13 at 01:00
The `port` parameter does double duty: it names the TCP socket and the Unix socket file too. (I consult on PostgreSQL through PGX Inc..)

permission denied for table in PostgreSQL: which grant?
Posted by Chris van Eijk on 2026-10-13 at 00:00
What raised 'permission denied for table', schema and sequence in PostgreSQL 17, measured: the privilege each statement needs, and why default privileges miss.

current_setting and set_config in PostgreSQL, measured
Posted by Chris van Eijk on 2026-10-13 at 00:00
What current_setting and set_config do with a custom setting in PostgreSQL 17, measured: NULL or empty string, how long a value lasts, defaults, who may set it.

What deleting rows does to a PostgreSQL table
Posted by Hollis Varden on 2026-10-13 at 00:00

A table that shrinks in rows does not shrink on disk. Everyone who has run PostgreSQL for a while knows this in general. I wanted the actual numbers, because "VACUUM reclaims space" means something narrower than it sounds.

Short answer: I deleted every second row of a 2,000,000-row table. The table was 137 MB before, 137 MB after the DELETE, 137 MB after VACUUM, and 68 MB after VACUUM FULL.

Setup

PostgreSQL 18.6, default settings, autovacuum on. 2020 13-inch MacBook Pro, Intel i5-8257U, 8 GB RAM. Sizes are pg_table_size. Times are wall clock for the statement, median of three runs, each on a freshly built table.

Deleting half the rows

step table size
2M rows, after VACUUM ANALYZE 137 MB
after DELETE FROM b1 WHERE id % 2 = 0 137 MB
after VACUUM b1 137 MB
after VACUUM FULL b1 68 MB

The DELETE marks rows dead. VACUUM makes their space reusable, so the next million inserts will fill those gaps instead of growing the file. It does not hand the space back to the operating system, with one exception: empty pages at the very end of the file get cut off. I deleted every second row, so every page kept half its rows and nothing at the end was empty.

VACUUM FULL writes a new copy of the table and drops the old one. That is why it gets the space back, and also why it takes a lock that blocks reads and writes while it runs.

DELETE or TRUNCATE to empty a table

time WAL written
DELETE FROM d1 (1M rows) 3.5 s 125 MB
[...]

Four PostgreSQL arguments that came out even
Posted by Hollis Varden on 2026-10-13 at 00:00

Some advice gets repeated in code review because it sounds like it should matter. I picked four I have seen argued about and measured them. I expected at least two clear winners. I got three ties and one result that went the opposite way from the advice.

Setup

PostgreSQL 18.6, default settings. 2020 13-inch MacBook Pro, Intel i5-8257U, 8 GB RAM. A 2,000,000-row table u with an id, an email, a status and a timestamp. Times are execution times from EXPLAIN (ANALYZE, TIMING OFF), warm cache, first run discarded, median of the rest.

IN, ANY or a VALUES join for 1,000 ids

median runs buffers
id IN (1999, 3998, ...) 26 ms 15 to 54 ms 3,001
id = ANY('{...}'::bigint[]) 19 ms 15 to 20 ms 3,001
JOIN (VALUES ...) v(i) ON id = i 20 ms 16 to 21 ms 3,001

All three read exactly the same pages. The medians differ, but one IN run took 54 ms and another 15 ms, so I would not read anything into the gap. Use whichever form your driver makes easy. ANY has one practical advantage when the array is passed as a single parameter: the statement text stays the same whatever the number of ids, which is kinder to prepared statements and to pg_stat_statements.

text, smallint or enum for a status column

Three values, two million rows, each stored three ways in its own one-column table.

table index
text 72.6 MB 13.9 MB
[...]

Why is my Whale Query 1000x Slower in Prod? Databases hate skew, each hates it differently
Posted by Alexander Ioffe on 2026-10-13 at 00:00
Ten enterprise customers own 80% of the orders. On uniform test data the query runs in ~1ms; on that real skew it runs ~1,000x slower. The fix doesn't transfer between engines: Postgres is rescued by one free session setting, SQL Server can't be touched by it and needs a completely different access-path fix. Measured on Neon and Azure SQL Database using ExoBench.

PostgreSQL row-level security for SaaS: what we measured
Posted by Chris van Eijk on 2026-10-12 at 23:15
Row-level security for a multi-tenant SaaS on PostgreSQL 17, result by result: what leaks, what it costs, how to set the tenant, and where each test is.

Go, pgx and PostgreSQL row-level security, measured
Posted by Chris van Eijk on 2026-10-12 at 23:15
Setting the tenant for PostgreSQL row-level security in Go with pgx 5.11, measured: pgxpool, PrepareConn hooks, transactions, batches and PgBouncer.

The Patch Is Coming From Inside the House
Posted by Christophe Pettus in pgExperts on 2026-10-12 at 16:00
On August 25, Robert Haas opened a pgsql-hackers thread like this: I asked Claude to evaluate which v19 patches were the scariest based on the number and type of bugs fixed post-freeze. Results below, with a few particularly cutting remarks from the LLM edited out. The subject line was “scary p… (I consult on PostgreSQL through PGX Inc..)

PostgreSQL RPM repository meets AI with pg_statviz
Posted by Devrim GÜNDÜZ in EDB on 2026-10-12 at 06:40
pg_statviz can now ask Claude, a local Ollama model, OpenAI or Gemini to explain your PostgreSQL statistics on every distro we ship it for. Getting there took three days and a few dozen new Python packages :-)

pg_statviz is a small tool that snapshots PostgreSQL's internal statistics and draws charts from them. Its newer releases also hand those numbers to an LLM and ask for an analysis. On Fedora this just worked, because Fedora ships fresh AI SDKs. On everything else, it did not -- until last weekend!
Continue reading "PostgreSQL RPM repository meets AI with pg_statviz"

PostgreSQL RPM repository meets AI with pg_statviz
Posted by Devrim GÜNDÜZ in EDB on 2026-10-12 at 06:40
pg_statviz can now ask Claude, a local Ollama model, OpenAI or Gemini to explain your PostgreSQL statistics on every distro we ship it for. Getting there took three days and a few dozen new Python packages :-)

pg_statviz is a small tool that snapshots PostgreSQL's internal statistics and draws charts from them. Its newer releases also hand those numbers to an LLM and ask for an analysis. On Fedora this just worked, because Fedora ships fresh AI SDKs. On everything else, it did not -- until last weekend!
Continue reading "PostgreSQL RPM repository meets AI with pg_statviz"

Contributions for week 40
Posted by Cornelia Biacsics in postgres-contrib.org on 2026-10-12 at 06:27

On 7 October, the London PostgreSQL Meetup group met.

Organizers:

  • Valeria Kaplan
  • Chris Ellis
  • Alastair Turner

Speakers:

  • Elizabeth Christensen
  • Alex Kasko
  • Jimmy Angelakos

On 8 October the PostgreSQL England North Meetup Group. Joseph Bharath Reddy Allam delivered a talk.

Organized by:

  • Daniel Chapman
  • Stephen Wood
  • Kate Gawron
  • Peter Schofield

On 8 October, the Greece PostgreSQL Users Group Meetup met. Avinash Vallarapu and Florents Tselai delivered a talk.

Organizers:

  • Florents Tselai
  • Eftychia Kitsou
  • Charis Charalampidi
  • Kostas Maistrelis

On 8 October, the Illinois Prairie PostgreSQL User Group met, organized by Henrietta Dombrovskaya and Carlos Aranibar. Devrim Gündüz delivered a talk.

On 9 October, PgPune took place.

Organized by

  • Ashish Kumar Mehra
  • Sachin D. Kotwal
  • Sagar Jadhav
  • Rushabh Lathia

Speakers:

  • Abhishek Oberoi
  • Anuj Sharma
  • Ashutosh Sharma
  • Debendra Saha
  • Deepak Mahato
  • Hari Kiran
  • Mukund Maheshwari
  • Nadeem Khan
  • Pushkar Khadilkar
  • Sneha Gohil
  • Tom Kincaid
  • Vishal Sawale

All Your GUCs in a Row: plan_cache_mode
Posted by Christophe Pettus in pgExperts on 2026-10-12 at 01:00
Override PostgreSQL's prepared statement plan choice when its cost estimates go wrong on skewed data. (I consult on PostgreSQL through PGX Inc..)

PGConf.EU Community Day: A Postgres Ecosystem Foundation?
Posted by David Wheeler on 2026-10-11 at 21:21

For anyone with an interest in the long-term health and longevity of the broader ecosystem of Postgres extensions and tools, we’d like to hear your ideas and inspirations for its assurance. Come to the PGConf.EU half-day Community Events Day session in València this year, cheekily called A Postgres Ecosystem Foundation?:

There are so many projects around Postgres which we rely on to extend functionality of the database engine, connect applications to the database, or simplify management and operations. Join us for an open discussion of the recent activity around developing the health of the ecosystem and what could be done to improve it further.

I’ll lead off with with a brief history of the work to create a “Postgres Ecosystem Foundation”. Then Peter Eisentraut will pitch some ideas to start organically building support for ecosystem projects and authors. Floor Drees, Alastair Turner, and Mark Wong will lay out potential topics and themes we missed. A few top-of-mind candidates from yours truly:

  • How to ensure the long-term viability of ecosystem projects
  • What to do about abandoned projects
  • How to share effort and cost amongst interested parties in the maintenance of ecosystem projects
  • What resources and services would best support ecosystem projects for the long term
  • How avoid license claw-back
  • What to do for maintainer retirement
  • How do we mentor and grow new maintainers
  • Increase visibility of projects
  • Raise and distribute funds for project maintenance
  • Provide additional community services like security scanning or packaging

Bring your own list! We’ll then organize around questions and concerns to open the floor for discussion.

We want your input!

We plan to take your input to start to develop concrete plans and socialize them to the rest of the community in the co

[...]

How TABLESAMPLE picks rows
Posted by Radim Marek on 2026-10-11 at 18:45

Most exploratory questions against a large table only need a rough answer, but without an index on status, even "roughly how many shipped orders" costs a full scan. On the two-million-row orders table, Postgres has to read every single 8 kB page, all 18,085 of them (141 MB), just to count matching rows. 

EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM orders WHERE status = 'shipped';
 Aggregate
   Buffers: shared hit=18085
   ->  Seq Scan on orders (actual rows=500000.00 loops=1)
         Filter: (status = 'shipped'::text)
         Rows Removed by Filter: 1500000
 Execution Time: 56.188 ms

shared hit=18085 is one buffer access per page, every page found already in memory (Reading Buffer statistics in EXPLAIN output goes through the counters). At 141 MB of heap size that's nothing. Take a 1 TB table with 134 million pages: a scan reads all of them from disk, every time, however small the answer is.

Postgres reads tables larger than a quarter of shared_buffers through a small ring buffer. See more in introduction to buffers.
At least Postgres avoids flushing its own cache by reading large tables through a small ring buffer. Nevertheless the disk still perform full read. On a primary server handling production traffic is shared with everything else. When all you need is exploratory confirmation "roughly how many" or "are there any representative samples" reading the whole terabyte is too expensive.

SQL Standard comes with TABLESAMPLE to help with that. It goes in the FROM clause right after the table name, and the rest of the query runs against the subset of pages it picks. 

SELECT
  id, status, created_at, amount
FROM orders TABLESAMPLE SYSTEM (1) REPEATABLE (7)
LIMIT 5;
 id  |  status   |       created_at       | amount
-----+-----------+------------------------+--------
 429 | delivered | 2024-01-01 00:07:09+00 |  38.46
 430 | delivered | 2024-01-01 00:07:10+00 | 150.72
 431 | delivered | 2024-01-01 00:07:11+00 | 295.59
 432 | delivered | 2024-01-01 00:07:12+00 | 488.23
 433 | delivered | 2024-01-01
[...]

All Your GUCs in a Row: password_encryption
Posted by Christophe Pettus in pgExperts on 2026-10-11 at 01:00
What `password_encryption` actually controls: how PostgreSQL hashes new passwords when you hand it clear text. (I consult on PostgreSQL through PGX Inc..)

All Your GUCs in a Row: parallel_leader_participation
Posted by Christophe Pettus in pgExperts on 2026-10-10 at 01:00
Whether your query's leader process joins the work or just supervises depends on this boolean, and the performance question it settles is subtle. (I consult on PostgreSQL through PGX Inc..)

All Your GUCs in a Row: parallel_setup_cost and parallel_tuple_cost
Posted by Christophe Pettus in pgExperts on 2026-10-10 at 01:00
PostgreSQL's parallel query planner charges two fees for going parallel: a setup cost per Gather node and a per-row cost for moving data from workers to… (I consult on PostgreSQL through PGX Inc..)

infinite recursion detected in policy: causes and fixes
Posted by Chris van Eijk on 2026-10-10 at 00:00
When PostgreSQL 17 raises 'infinite recursion detected in policy for relation', and what each fix costs on a million rows: from 0.09 ms to 6.6 seconds.

new row violates row-level security policy: the causes
Posted by Chris van Eijk on 2026-10-09 at 23:15
What raised 'new row violates row-level security policy for table' in PostgreSQL 17, measured: inserts, RETURNING, upserts, MERGE and four message forms.

Scaling Citus without limits: announcing Query Routers in StackGres
Posted by Álvaro Hernández in OnGres on 2026-10-09 at 16:14

Citus already scaled the workers horizontally. Now the coordinators too

I’ve heard more than once that Citus is not a good sharding technology/architecture because it’s limited to one coordinator. That’s not completely untrue:

  • A single coordinator can scale clusters to very large workloads with multiple workers. But the coordinator is the sole entry point and, at some point, it can become the bottleneck. It’s a ceiling.

  • Citus supports querying workers directly since version 11, where workers behave as coordinators from a query routing/execution perspective. However, using workers as coordinators makes query routing and data processing contend for the same resources, which is far from ideal.

This post introduces the concept of Query Routers for Citus, an innovation that shipped in StackGres 1.19. StackGres already had a deep integration with Citus, making it easier than ever to create sharded clusters with Citus. Now it also adds the capability to scale coordinators horizontally; we call this Query Routers. And they remove the scaling limit that single-coordinator Citus has. With query routers there isn’t, in principle, any limit to scaling Citus.

The single coordinator limit

So where’s the limit, after all? Let’s first analyze the architecture. For standard Citus clusters, there was a single place where clients connect: the coordinator. For each query, the coordinator accepts the connection, parses the statement, plans it, works out which shard(s) hold the data to answer the query, opens or reuses connection(s) to the worker(s) that store the involved shards, forwards the query, and aggregates/relays/post-processes the result. All of that happens on one node.

Adding workers spreads the data and the storage work over more machines; the entry path still runs through one Postgres instance on one set of vCPUs, and the workers behind it can only be as busy as that one node allows.

This is the architecture of a typical (single-coordinator) Citus c

[...]

Portions Copyright
Posted by Christophe Pettus in pgExperts on 2026-10-09 at 13:51
In October 2014, a developer wrote to a PostgreSQL mailing list with a problem. His employer’s open source office required a signed contributor license agreement before he could contribute, and he could not find PostgreSQL’s. Tom Lane answered: There are no such agreements for Postgres work. The… (I am not a lawyer, and this is not legal advice.) (I consult on PostgreSQL through PGX Inc..)

PG Phriday: Against the WAL
Posted by Shaun Thomas in pgEdge on 2026-10-09 at 12:14

Plenty of Postgres services end up managed by application developers, whether they like it or not. Some dabble in databases on the side, and some inherited the job when the last DBA scampered off for greener pastures. Regardless, they’re put in charge of something they barely understand. Heck, that literally happened to me twice. Sometimes there never was a DBA. Sometimes, it's just you.I recently got a timely reminder of this when chatting with a colleague. Usually when it comes to Postgres, disk emergencies get traced back to the  directory. For an amateur or novice DBA, the first reaction might be to purge its contents in any way possible. What is all this WAL junk, anyway? It's just for crash recovery or something, right? The logs say the archive command is failing, so I can just set  to  and it'll flush all that out. Easy peasy.Oh how we all wish it were that simple. WAL is the single linchpin that keeps Postgres operational at all. It's the Durability in the ACID acronym commonly associated with relational databases. In Postgres, literally every write must pass through the WAL. But why would an app dev know that? Why would anyone aside from a seasoned DBA need to know it at all?Fortunately the reality of the situation is actually incredibly easy to convey. I always like to start with something pretty much everyone has: a bank account.

Balancing the Books

A bank ledger starts with an opening balance. After that comes every deposit and every withdrawal, one line at a time, in the same order they happened. The balance printed at the bottom of a statement is a convenient aggregate summary. It's derived from the ledger, and any auditor can validate it by running the sum themselves.Now tear one page out of the middle of the ledger. Would you trust anything that came after? Even assuming the final total somehow survived because it was calculated earlier, who can say whether or not it's true now?Postgres works the same way. The data files holding tables and indexes are the balance, and the WAL is the ledger.[...]

The Database Restarted Without Restarting: The Basics of PostgreSQL Signals (Part 1)
Posted by SHRIDHAR KHANAL in Stormatics on 2026-10-09 at 09:36

Key Takeaways 

  • Signal 1 (SIGHUP) normally tells PostgreSQL to reload its configuration. A log line saying a process was terminated by signal 1 means that process didn’t handle the signal and died from it.
  • received SIGHUP, reloading configuration files is a harmless reload. server process (PID …) was terminated by signal 1: Hangup is a death report.
  • When any child of the postmaster is killed by a signal, PostgreSQL drops every connection, resets shared memory, and replays WAL. The postmaster keeps its process ID, so the server never appears to restart.
  • Running kill -9 on a single backend triggers the same server-wide reset. Use pg_cancel_backend() first, and pg_terminate_backend() only if needed.

Imagine you’re reviewing your PostgreSQL logs and you find this line:

LOG:  server process (PID 48213) was terminated by signal 1: Hangup

Right after it, PostgreSQL went through crash recovery. Every connection dropped, the application threw errors for about half a minute, and then everything came back as if nothing had happened.

So you start investigating. The server never restarted, and the main PostgreSQL process still has the same process ID it had yesterday. Nobody ran a deployment, and nobody on the team admits to touching anything. You search the log for a configuration reload and find nothing. A few days later, the same line appears again at a completely different time.

To make it stranger, signal 1 is the signal PostgreSQL uses to reload its configuration. Normally it causes no harm at all: PostgreSQL re-reads its settings and carries on. So why is it showing up in a crash log?

To answer that, we need to understand what signals are and how PostgreSQL reacts to them. Let’s start with the basics.

What is a Signal?

A signal is a small notification sent to a running program, eithe

[...]

Postgres relation files, filed under base/
Posted by Radim Marek on 2026-10-09 at 06:45

The buffers article followed an 8KB page from disk into shared memory and back. What it didn't do is name the file. Every page that passes through the buffer pool is block number N of some file under the data directory, and the file has a naming scheme, a size limit, and companion files that share its name. Before the next article reads the inside of a page, this one finds it on disk with ls and od, and shows that the bytes are the same ones.

Nothing here needs more than a scratch database and shell access to its data directory. The examples were captured on PostgreSQL 18.6 with data checksums on, which is the default since 18.

Setup 

CREATE EXTENSION IF NOT EXISTS pageinspect;

CREATE TABLE files_demo (
    id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    title text NOT NULL,
    value numeric(10,2)
);

INSERT INTO files_demo (title, value)
SELECT 'row_' || i, i * 1.5 FROM generate_series(1, 1000) AS i;

A thousand short rows and a primary key. The text column is there so a TOAST table gets created.

From table name to file name

The function that answers "where is this table on disk" ships with the server: 

SELECT pg_relation_filepath('files_demo');
 pg_relation_filepath
----------------------
 base/5/16431
(1 row)

The path is relative to the data directory (SHOW data_directory prints it). Three parts: base is the directory for the default tablespace, 5 is the OID of the database, and 16431 is the file's name. That last number is the relfilenode, and it comes from pg_class: 

SELECT oid, relfilenode, relname
FROM pg_class
WHERE relname LIKE 'files_demo%';
  oid  | relfilenode |      relname
-------+-------------+-------------------
 16431 |       16431 | files_demo
 16430 |       16430 | files_demo_id_seq
 16438 |       16438 | files_demo_pkey
(3 rows)

Three relations, three files. The identity column's sequence and the primary key index each get their own, because to the storage layer a sequence is one-page relation and an index is a relation like any other. The oid and relfilen

[...]

The reverts will continue until morale improves
Posted by Peter Eisentraut in EDB on 2026-10-09 at 04:00

Many readers will be aware that an unusually high number of features have been reverted from the PostgreSQL 19 branch after the beta period began. Having some reverts is not unusual, maybe one per cycle could be expected. But this time around, about 8 to 10 significant features, depending on how you count, have been reverted, and some of them quite late in the beta period. I have been on the receiving end of some of that, as the developer or committer of some of those features, and have gotten some questions about it, and so I want to take a moment to reflect on this. I’ll try to extrapolate a little bit to similarly affected work that I was not actively involved in, but these are just my opinions at this point.

So what happened?

I don’t think we, meaning all the developers affected, have had enough time to fully reflect on all this. But here are some thoughts. It’s probably a combination of these, and a different combination in the case of each reverted feature.

  • Maybe we just didn’t do a good enough job. Maybe the code was just not good enough. We’ll learn and improve. It’s probably some of that, and I’m mentioning it here to not give the impression that it was only the other factors that I’m going to mention.

  • It could also be a coincidence. Maybe we had been on such a good roll that we attempted to tackle several features that turned out to be too hard, or at least too hard to finish in time.

  • Some of the reverted features had significant architectural defects that would have been hard to fix quickly and during beta. But there was also a long tail of relatively harmless issues involving various edge cases. In past times, many of these would not have surfaced until much later and we would have fixed them bit by bit over the subsequent five years. But with LLM-assisted code review, these kinds of things can get found much faster, and then you’re staring at a list of like forty defect reports. And even if each of them requires only a three-line

[...]

Top posters

Number of posts in the past two months

Top teams

Number of posts in the past two months

Feeds

Planet

  • Policy for being listed on Planet PostgreSQL.
  • Add your blog to Planet PostgreSQL.
  • List of all subscribed blogs.
  • Manage your registration.

Contact

Get in touch with the Planet PostgreSQL administrators at planet at postgresql.org.