Latest Blog Posts

pg_clickhouse 0.3.1: Now With More C
Posted by David Wheeler on 2026-06-03 at 20:13

Hello listeners!

Yesterday, with little fanfare (yay 🎉) we pushed out a minor release to pg_clickhouse, the interface for querying ClickHouse from Postgres. As with previous minor releases, yesterday’s v0.3.0 release requires no reload, restart, or ALTER EXTENSION UPDATE, just reload your session when you’re ready and you’re good to go.

But don’t let the minor version increment deceive you: we made a significant change to pg_clickhouse in this version. What change, you ask? Here it is:

We replaced the clickhouse-cpp library powering the binary driver with the new clickhouse-c library written by my colleague Philip Dubé (a.k.a., serprex). This header-only client library provides a number of substantial benefits vs. the clickhouse-cpp library we previously vendored:

  • Eliminates incompatibility between C++ raise/throw & RAII and Postgres PG_TRY & setjmp/longjmp. The result is much more stable code paths with susceptibility to crashes.
  • Allows us to strictly use Postgres memory contexts, rather than having to deal with both Postgres and C++ allocation patterns, thanks to the library’s support for specifying the memory allocation functions to use.
  • Eliminates the overhead of vendored code, notably absl and cityhash. It does now require liblz4 and libzstd packages, in addition to the previously-required libcurl, uuid, and libssl, but this pattern makes it far more friendly to packager.
  • Far faster compile times and resulting binary. On my M4 MacBook Pro, compiling, installing, and running all the tests now takes around 2 seconds! Meanwhile, the binary size has dropped from 1.8 MB to around 400 KB; on x8664 Linux it went from 4.9 MB to 1.4 MB!

Big change under the hood! Plus a bug fix to properly convert UInt16 values to int32 instead of int16. This is a good one. Get it from the usual suspects:

[...]

Handling graphs with SQL/PGQ in PostgreSQL
Posted by Hans-Juergen Schoenig in Cybertec on 2026-06-03 at 06:51

Starting with version 19 of PostgreSQL users will be able to enjoy something exceptionally useful which will help developers to build even more powerful applications even more quickly. SQL/PGQ — the ISO/IEC 9075-16 (2023) syntax for querying graphs that live in regular relational tables - will be available. This series of posts will explain how this new functionality works and how it can be used to leverage the power of PostgreSQL 19 and beyond.


Your First Graph Query in PostgreSQL 19

The addition introduces two SQL constructs: Namely CREATE PROPERTY GRAPHand GRAPH_TABLE. Let us take a look at the definition of the property graph: 

friends=# \h CREATE PROPERTY GRAPH
Command:     CREATE PROPERTY GRAPH
Description: define a new SQL-property graph
Syntax:
CREATE [ TEMP | TEMPORARY ] PROPERTY GRAPH name
    [ {VERTEX|NODE} TABLES ( vertex_table_definition [, ...] ) ]
    [ {EDGE|RELATIONSHIP} TABLES ( edge_table_definition [, ...] ) ]

where vertex_table_definition is:

    vertex_table_name [ AS alias ] 
[ KEY ( column_name [, ...] ) ] 
[ element_table_label_and_properties ]

and edge_table_definition is:

    edge_table_name [ AS alias ] [ KEY ( column_name [, ...] ) ]
        SOURCE [ KEY ( column_name [, ...] ) 
REFERENCES ] source_table [ ( column_name [, ...] ) ]
        DESTINATION [ KEY ( column_name [, ...] ) 
REFERENCES ] dest_table [ ( column_name [, ...] ) ]
        [ element_table_label_and_properties ]

and element_table_label_and_properties is either:

    NO PROPERTIES | PROPERTIES ALL COLUMNS | PROPERTIES 
( { expression [ AS property_name ] } [, ...] )

or:

   { { LABEL label_name | DEFAULT LABEL } 
[ NO PROPERTIES | PROPERTIES ALL COLUMNS | PROPERTIES 
( { expression [ AS property_name ] } [, ...] ) ] } [...]

URL: https://www.postgresql.org/docs/devel/sql-create-property-graph.html

Before we dig into this in more detail we need to understand what the purpose of all of this is: In a relational database things are stored as tables. What CREATE PROPERTY GRAPH does is to defi

[...]

pg_stat_statements: everything it can't
Posted by Radim Marek on 2026-06-03 at 06:45

Part one made the core case: pg_stat_statements counts, it doesn't record. It walked through how the queryid jumble fragments one logical query into many rows, how the first-seen text freezes your per-request tags, and how the averages bury the p99 that actually pages you. All of that was about data the extension has and distorts.

This part is about the rest: the entries it silently throws away, the query text that can vanish all at once, the plans and replicas it never records, and the knobs that bite. It ends where part one started, with the question the whole investigation was really about: is this the query store Postgres is missing, or just the floor you'd build one on?

The table fills up and evicts your tail

pg_stat_statements.max defaults to 5000. It's a hard cap on entries, set when the server starts (changing it needs a restart, because the hash table is sized in shared memory up front). When the 5001st distinct shape arrives, Postgres doesn't grow the table. It evicts, throwing out the least-executed entries to make room:

If more distinct statements than that are observed, information about the least-executed statements is discarded.

On a healthy app with a few hundred steady shapes, 5000 is plenty and you never think about it. But remember the row explosion from part one. An ORM that splinters one query into hundreds of shapes, or a pre-18 app building dynamic IN lists, can chew through thousands of entries an hour. Once that starts, the view becomes a sliding window over recent noise. Your steady, important queries get evicted to make room for thousands of one-offs, then rebuilt with fresh counters and a fresh first-seen text when they run again. The stats you were trusting reset themselves, and the view never says a word about it.

One place does say something. The companion view pg_stat_statements_info has exactly two columns, and both matter: 

SELECT dealloc, stats_reset FROM pg_stat_statements_info;
 dealloc |          stats_reset
---------+-----------------------
[...]

All Your GUCs in a Row: createrole_self_grant
Posted by Christophe Pettus in pgExperts on 2026-06-03 at 01:00
PostgreSQL 16 overhauled role management to tame the near-superuser power of CREATEROLE.

pg_stat_statements: everything it tells you
Posted by Radim Marek on 2026-06-02 at 20:15

If not first, pg_stat_statements is one of the most used extensions in the PostgreSQL ecosystem. It ships in contrib and costs almost nothing to use. Most of us turn to it to answer the question: what is the database actually doing? It's genuinely useful. You can use it to get a snapshot of what happened in a given timeframe, and make a faster decision about what to fix.

Coming from other database engines, you might reach for it expecting something a bit more, a query store. The built-in feature that keeps normalized queries and their plan history. Except pg_stat_statements is not this. This article is going to deep dive into what the extension really provides.

Because once you lean on it, you might start noticing the rough edges. The gap comes from what "a query store" might come with and what it actually tells you.

The very same query might show up in many separate rows. Discrepancies between what your monitoring says and what mean_exec_time shows. Missing queries. Numbers that changed overnight.

None of that is a bug. It all follows from what pg_stat_statements really is: a fixed-size hash table of running counters, kept in shared memory, keyed by a hash of your parse tree. It counts; it does not record. Hold that one idea in your head and every surprising thing on the list above stops being surprising.

Everything below is reproducible. Paste this into a scratch database: 

CREATE TABLE customers (
    id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name text NOT NULL
);

CREATE TABLE orders (
    id integer GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id integer NOT NULL REFERENCES customers(id),
    amount numeric(10,2) NOT NULL,
    status text NOT NULL DEFAULT 'pending',
    created_at timestamptz NOT NULL DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO customers (name)
SELECT 'Customer ' || i FROM generate_series(1, 2000) AS i;

INSERT INTO orders (customer_id, amount, status, created_at)
SELECT (random() * 1999 + 1)::int,
       (random() * 500 + 5)::numeric(10,2),
[...]

Hacking Workshop for June/July 2026
Posted by Robert Haas in EDB on 2026-06-02 at 18:36
I was hoping to usual resume the monthly cadence of hacking workshops in June, but it didn't quite happen, largely due to being a little exhausted after pgconf.dev. But, I'm pleased to announce that Melanie Plageman will be joining us to discuss her talk Additional IO Observability in Postgres with pg_stat_io. If you're interesting in joining us, please sign up using this form and I will send you an invite to one of the sessions. As always, thanks to Melanie for joining us.Read more »

Managed Postgres, Examined: Azure Database for PostgreSQL Flexible Server
Posted by Christophe Pettus in pgExperts on 2026-06-02 at 15:00
Azure's managed PostgreSQL differs from competitors by putting the standby in the commit path—every write waits for synchronous replication to a second server…

The Night Our Tables Wouldn’t Stop Growing
Posted by semab tariq in Stormatics on 2026-06-02 at 10:38

We were doing everything right. The migration plan was solid, the team was experienced, and we had done this kind of thing before. But somewhere around midnight, someone on the team noticed something strange. Tables on the destination side were ballooning at an unexpected rate with hundreds of gigabytes being used, while the source side tables sat quietly at just a few megabytes.

Something was very wrong, and we had no idea what.

How It Started

The customer had a PostgreSQL database that they wanted to migrate to a new server. The approach was a logical replication

The initial step in logical replication is the initial table copy. PostgreSQL copies all the existing rows from the source to the destination before replication kicks in and starts streaming live changes. For most tables, this is quick and uneventful.

But when we checked on things the next morning, the picture was not pretty.

What We Saw

On the source side, the tables looked completely normal. Some were 50 GB, some were 90 GB, and a few were just megabytes. Nothing unusual.

On the destination side, the subscriber had a few of those same tables that had grown to over 400 GB each. Overnight. Tables that were 50 to 90GB on the source were now hundreds of gigabytes on the destination, and they were still growing.

What Was Happening

After digging in, we found the culprit. It was statement_timeout.

statement_timeout is a PostgreSQL setting that tells the database, “If any query or operation runs longer than X amount of time, kill it.” It is a sensible safety net. You do not want runaway queries eating resources forever on a production system.

The problem was that on the publisher server, statement_timeout was set to a relatively low value(1 min). And the initial table copy during logical replication setup, which is essentially one big, long-running operat

[...]

When is a function leakproof?
Posted by Laurenz Albe in Cybertec on 2026-06-02 at 05:37

A plumber's advice: I'm not sure about making functions leakproof, but have you tried a few layers of duct tape?
© Laurenz Albe 2026

Instigated by a customer, I've been trying to improve the performance of row-level security. Central to good performance in this area is the concept of leakproof functions and operators. I'll go over the priciples quickly, but I'll focus on the question what leakproof really means, and what it should mean. In a way, this article is a request for comments: I'd be curious what you think about the topic!

Security barrier views and row-level security

PostgreSQL has two related features to hide table rows from a user: Security barrier views and row-level security. The usual reason why you want to hide parts of a table is multi-tenancy: you want to store data belonging to different entities (tenants) in a single table, and you want to prevent any tenant from seeing or manipulating the other tenants' data. You can certainly implement such restrictions in the application code. However, having a ready-made reliable solution inside the database is a good thing.

Security barrier views

This is the older of the two techniques, introduced in PostgreSQL 9.2. It makes use of how PostgreSQL checks the privileges on the objects used by a view: as long as the owner of the view has the permission to access the objects, anybody with privileges on the view can use it. That makes definitions like the following feasible: 

CREATE TABLE account (
   account_nr bigint        PRIMARY KEY,
   owner      text          NOT NULL,
   amount     numeric(15,2) NOT NULL
);

CREATE INDEX account_owner_idx ON account (owner);

CREATE VIEW my_account AS
   SELECT account_nr, owner, amount
   FROM account
   WHERE owner = current_user;

GRANT SELECT, INSERT ON my_account TO PUBLIC;

Using the view, every database role can look at their own account, even though they don't have any privileges on the account table.

Note that I also granted everybody the INSERT privilege on the view. It may surprise some people, but you can also use data modifying statements on views (provided that the view definition is

[...]

All Your GUCs in a Row: cpu_index_tuple_cost, cpu_operator_cost, and cpu_tuple_cost
Posted by Christophe Pettus in pgExperts on 2026-06-02 at 01:00
cpu_tuple_cost, cpu_index_tuple_cost, and cpu_operator_cost are three of the constants the planner uses to price a query, and the single most useful thing to know about all three is that you should almost certainly never change them. The rest of this post is why. PostgreSQL’s planner does not est…

SQL/PGQ in PostgreSQL 19: Graph Queries Without the Graph Database
Posted by Christophe Pettus in pgExperts on 2026-06-01 at 15:00
PostgreSQL 19 adds GRAPH_TABLE, letting you query property graphs with Cypher-like pattern matching over your existing relational tables.

Contributions for week 21, 2026
Posted by Cornelia Biacsics in postgres-contrib.org on 2026-06-01 at 11:35

On May 26 2026, the Bratislava PostgreSQL Meetup came together, organized by Pavlo Golub and Meego Smith. Mayur B. and Devrim GĂĽndĂĽz delivered a presentation.

About 90 attendees showed up for the NYC Postgres meetup that took place May 27 with Gleb Otochkin speaking.

Organizers:

  • Xuan Tang
  • Mason Sharp
  • Mila Zhou
  • Justin Iso
  • Lloyd Massiah

On Thursday, 28 May, the PostgreSQL User Group Vienna met for a casual networking event, organized by Cornelia Biacsics.

On Friday, 29 May 2026 the Ghana PostgreSQL Users Group met for the first virtual meetup, organized by Benedict Kofi Amofah and Ezra Yendau

Community Blog Posts

PGConf.be 2026
Posted by Wim Bertels on 2026-06-01 at 11:07

A round up of the sixth PGConf.be

The shared presentations are online, as are a couple of recordings and turtle-loading have-a-cup-of-tea locally stored photos.

Using the well known and broadly spread technique of inductive reasoning we came to the conclusion that this fifth PGConf.be conference was a success, as well as the art work. No animals or elephants we’re hurt during this event.

The statistics are

  • 75 attendants

    • depending on the session, an extra 200 students attended as well

  • 14 speakers

  • 4 sponsors

This conference wouldn’t have been possible without the help of volunteers.
To conclude a big thank you to all the speakers, sponsors and attendants.
Without them a conference is just a like tee party.

All Your GUCs in a Row: constraint_exclusion
Posted by Christophe Pettus in pgExperts on 2026-06-01 at 01:00
Skip partition scanning with constraint_exclusion, PostgreSQL's old pruning trick.

All Your GUCs in a Row: config_file
Posted by Christophe Pettus in pgExperts on 2026-05-31 at 01:00
PostgreSQL's `config_file` parameter creates a bootstrap paradox: it tells the server where to find its configuration, but lives on the command line only—never…

All Your GUCs in a Row: compute_query_id
Posted by Christophe Pettus in pgExperts on 2026-05-30 at 01:00
PostgreSQL 14 unified query-id computation across all subsystems, but defaulting to always-on would tax every backend.

Open-Source TDE for PostgreSQL: What pg_tde Is, and Whether You Need It
Posted by Christophe Pettus in pgExperts on 2026-05-29 at 15:00
PostgreSQL finally has an open-source Transparent Data Encryption option.

Looking Forward to Postgres 19: The New REPACK Command
Posted by Shaun Thomas in pgEdge on 2026-05-29 at 09:21

Postgres has had a thorn in its paw for a very long time regarding table size. Every modified tuple leaves an old version in the heap for use by older transactions. While  locates these old tuples, it only marks them as reusable rather than returning the space to the OS. Tables only ever grow larger in Postgres.Maybe Postgres 19 can fix that for us.

Options Galore

Historically, the only sanctioned solutions to table bloat have been the VACUUM FULL or CLUSTER commands. Sadly, both of these require an  lock for the entire duration of the operation. In a world where 1TB tables aren't uncommon, it's a ridiculous imposition that's entirely incompatible with a production system.So the community turned to third-party utilities like pg_repack and pg_squeeze, which rewrite tables with minimal locking by leveraging logical decoding under the hood. Some DBAs even run these on a regular schedule to keep tables at their ideal size at all times. But more conservative shops have always been wary of handing table rewrites to a project that operates outside the core engine's safety guarantees. I've personally handled support tickets to repair corruption caused by . While that may have been several years ago, it's enough to induce extra caution rather than reliance.Postgres 19 may prove to change things entirely. The new REPACK command brings this functionality into the core engine itself, complete with a  option that eliminates the prolonged exclusive lock. And as an added bonus,  and  now use the same repack infrastructure internally, so every path to table compaction benefits from the new code.

An Ounce of Prevention

Before we get too excited about our shiny new tool, let's pull back and talk about not needing it. The best repack is the one you never have to run.Postgres ships with autovacuum enabled by default, and for many workloads, the defaults are perfectly fine. For tables with high churn, especially those that see large batch deletes or frequent updates, the defaults tend to be insufficient.The usual fix isn't [...]

PGConf.dev 2026: Our team’s sessions, working groups, and key takeaways
Posted by Floor Drees in EDB on 2026-05-29 at 09:15

Last week, we attended the annual PGConf.dev as a Gold-level sponsor. While most PostgreSQL conferences usually attract users and DBAs, this event draws a strong mix of contributors and community members alike, making it a unique opportunity to get proposals and patches reviewed and to connect across the broader Postgres ecosystem. 

Our team played a major role behind the scenes. Robert Haas helped organize the event, tackling the impressive feat of shaping Tuesday's content across six tracks. Additionally, Jacob Champion served on the Talk Selection Committee, and Phil Alger, Manni Wood

All Your GUCs in a Row: commit_timestamp_buffers
Posted by Christophe Pettus in pgExperts on 2026-05-29 at 01:00
PostgreSQL 17 made SLRU buffer pools configurable for the first time.

Memories from PGConf.dev 2026
Posted by Stefan Fercot in Data Egret on 2026-05-28 at 15:04

Thanks to the organising team, I had the chance to attend PGConf.dev last week in Vancouver, Canada. And luckily, I wasn’t alone there — Valeria could join as well!

This year’s edition was particularly special: we celebrated 30 years of open source PostgreSQL together! Many activities revolved around the anniversary, including a special celebration-themed conference t-shirt, stickers, commemorative posters, and more.

My personal highlight was definitely Wednesday’s round-table retrospective, which brought together project founders and early contributors to reflect on PostgreSQL’s formative years and its remarkable evolution. Featuring Bruce Momjian, Tom Lane, Thomas Lockhart, Jan Wieck, Vadim Mikheev, and Jolly Chen, the discussion revisited what the Postgres project was like in its earliest open source incarnation — technically, culturally, and socially.

Then, on Thursday, a birthday cake cutting ceremony took place following a short speech from Bruce Momjian.

Even though the project still relies on decisions made in its early days — such as hacker mailing-list-focused discussions and documentation written close to the source code using DocBook — it is hard to imagine where PostgreSQL will be 10 or 20 years from now.

Especially today, with AI-assisted content generation accelerating code writing (though not necessarily code review!), the project will inevitably evolve. But as Jan Wieck concluded during the panel, we should take care to preserve and foster the PostgreSQL spirit.

After the panel, a group photo was organised. I can’t wait to see the result!

Speaking of pictures, a photo booth was set up to let attendees take funny pictures celebrating PostgreSQL’s 30th anniversary. As member of the PGDay Lowlands 2026 talk selection committee, I couldn’t resist taking a picture together with Floor Drees, who was the only representative from the organising team attending the event.

This year’s PGConf.dev schedule was divided into three parts.

Tuesda

[...]

Twenty Years, Three CVEs, One AI
Posted by Christophe Pettus in pgExperts on 2026-05-28 at 15:00
Three heap buffer overflows in PostgreSQL — including a 20-year-old pgcrypto bug — were found by an AI code analyzer. But.

Postgres as an Execution Environment for AI: Failure Modes, Hooks, and the ORBIT Framework
Posted by Vibhor Kumar on 2026-05-28 at 12:50

A field report from PGConf Dev 2026 — and a working framework for everyone who has to keep AI workloads running in production.

It’s 3:47 AM. The Pager Goes Off.

A production AI batch job is stuck. Sixty thousand rows are locked. Your application performance is degrading. The post-mortem the next morning will be filed under “unknown cause.”

Here is what actually happened, minute by minute:

  • T+00:00 — The summarization job kicks off. Two hundred workers open transactions, query rows, and call out to an LLM provider.
  • T+00:32 — The LLM provider hits a rate limit and returns HTTP 429 across all two hundred concurrent calls simultaneously.
  • T+00:32 — Every worker retries. All of them. At the same instant. Still inside their open transactions. Row locks still held.
  • T+01:04 — Retry storm number two. PgBouncer’s pool is exhausted. Normal application traffic now starts failing, too.
  • T+01:36 — The on-call engineer wakes up and finds pg_stat_activity full of “idle in transaction.”
  • T+03:47 — The table is finally vacuumed. Service restored.

The root cause has a name, but it’s a name the industry hasn’t agreed on yet: external call state held inside an open transaction. There is no alert for it. There is no entry in the runbook. There is no metric you can graph. The post-mortem says “unknown cause” because we don’t yet have a shared vocabulary for this failure mode.

I gave a talk at PGConf Dev about this and a class of related production incidents. By the end of the session, I wanted the audience to walk away with two things: enough technical understanding to fix something on Monday morning, and enough conceptual vocabulary to argue for the right primitives in the Postgres community.

This post is the long-form version of that talk. It introduces a five-letter framework — ORBIT — that maps every failure mode I’ll discuss to one of five principles, and shows how the same framework applies whether you’re an SRE staring at a pager, an Enterp

[...]

Automating PostgreSQL Index Tuning Using AI
Posted by warda bibi in Stormatics on 2026-05-28 at 11:45

If you have a slow query, one of the obvious moves is to add an index. So you look at the WHERE clause, pick a column, run CREATE INDEX, and test again. Sometimes it helps, often it doesn’t. And now you have an index sitting there, not helping reads, but slowing down every write, because INSERT, UPDATE, and DELETE all have to maintain it. And it gets worse as your system grows.

Five queries are manageable. You can reason about column choices, test combinations, and check EXPLAIN output. When you are dealing with fifty queries across a dozen tables,  you are evaluating hundreds of possible column combinations manually, each one potentially breaking something in production if you get the locking wrong. 

Why index tuning is harder than it looks

Most people know that indexes speed up reads. Fewer people think carefully about what actually happens when they add one.

First, PostgreSQL might not use it. The planner compares strategies and picks the cheapest one. If your query touches a large fraction of the table, a sequential scan might actually be cheaper than an index scan. Creating the index doesn’t change that math, it just adds overhead.

Second, even with CONCURRENTLY, creating an index on a busy table isn’t free. It competes with your workload, can cause replication lag, and sometimes it times out. People don’t plan for this until it happens at 2am.

Third, and this one is subtle, adding the wrong index is sometimes worse than adding nothing. You pay the write overhead with zero read benefit.

The harder part is column ordering. A composite index on (status, customer_id) and one on (customer_id, status) are completely different things. The planner’s decision about which one to use depends on your data distribution, which conditions appear in your WHERE clause, and how selective each column is. Getting this wrong by hand is easy. Verifying it without touching production is the real challenge.

The idea behind automation

[...]

How to hack Logical Replication in PostgreSQL: Insights from contributors
Posted by Hayato Kuroda in Fujitsu on 2026-05-28 at 01:05
How to hack Logical Replication in PostgreSQL: Insights from contributors

Logical replication has come a long way since its introduction in PostgreSQL. It is now being adopted more widely than ever, powering cross-version upgrades, multi-region deployments, and real-time analytics pipelines. Yet significant opportunities for improvement still remain.

 

All Your GUCs in a Row: commit_delay and commit_siblings
Posted by Christophe Pettus in pgExperts on 2026-05-28 at 01:00
Tune `commit_delay` to batch WAL flushes and trade latency for throughput—but only if `pg_test_fsync` proves sync time is your bottleneck.

REPACK CONCURRENTLY: pg_squeeze Gets a Promotion
Posted by Christophe Pettus in pgExperts on 2026-05-27 at 15:00
PostgreSQL 19 brings REPACK CONCURRENTLY, a native alternative to pg_repack that rewrites tables without crippling locks.

Postgres War Stories Part 1: Postgres outages that aren't Postgres bugs
Posted by Payal Singh in Instaclustr on 2026-05-27 at 13:00

This series is aimed at recounting, explaining, and cataloging issues pertaining to Postgres in large-scale production environments that affected a wide section of users and clients. The idea occured to me when discussing one specific issue (covered in a later part in this series) that was my first experience dealing with such issues on a wide scale (multiple clients and clusters affected). This specific part focuses on issues that were caused not by Postgres itself, but by the tools, OS, and ecosystems that Postgres relies on.

Three of the worst Postgres incidents I have read postmortems for did not start in Postgres. They started one layer down: the kernel, glibc, the page allocator. Postgres handled the input correctly given what it was told.

I want to cover these first because the fixes are cheap and most teams still ship without them.

fsyncgate (2018)

For years, Postgres assumed that if fsync() returned success, the data was on disk, and if it returned an error, it could be retried. Linux did neither. Under writeback errors on some filesystems, the kernel cleared the error after the first reader saw it. The next fsync() returned success while pages were still dirty in memory and never made it to disk.

This came to be known as fsyncgate. The fix in Postgres was to PANIC on fsync() failure (PG 11+), forcing recovery from WAL instead of trusting the OS to retry. There is also data_sync_retry, which you almost certainly want set to off.

What this means for an operator:

  • If you run anything older than PG 11, plan the upgrade. There is no clever workaround.
  • Alert on PANIC events in the logs. They are rare, and they are how the database tells you the OS just admitted to lying.
  • If you use a network or shared filesystem, confirm it actually honors fsync semantics. Many do not, and the docs rarely say so plainly.

For the long version of how this came to light on the pgsql-hackers list, Jonathan Corbet's PostgreSQL's fsync() surprise on LWN is the canonical writeup.

gl

[...]

Graph Queries in Postgres with Apache AGE
Posted by Elizabeth Garrett Christensen in Snowflake on 2026-05-27 at 07:00

The Iceberg tables look like normal Postgres tables. You create them with USING iceberg and they're backed by Parquet on S3:

Postgres engines now have access to more data than ever. With extensions like pg_lake, you can connect Postgres to gobs of files in object storage like csv, json, Apache Parquet™ and Apache Iceberg™.

But having access to data in object storage and being able to aggregate data in object storage are two different things. This blog walks through the Postgres extension, Apache AGE™, that makes working with huge files of data sets much friendlier through graph relationships.

Why graph matters for data lakes

Let's consider a healthcare network with providers, patients, facilities and referral chains. The analytical questions are straightforward:

  • What's the total billed amount per region?
  • Which patients have the highest spend?
  • What's the average claim by specialty?

SQL on Iceberg handles all of these beautifully. But if you need to know: "Which in-network providers are referring patients to out-of-network providers through chains of intermediaries, and what's the dollar impact?" Those questions have two parts: a graph traversal (find the referral chains) and an analytical aggregation (sum the costs). Neither a pure graph database nor a pure analytical engine can answer it alone. You need both, working together, in the same query.

This is where data lakes need graphs.

Why Apache AGE

Apache AGE is a PostgreSQL extension that adds openCypher graph query support directly inside Postgres. There are other graph databases out there — Neo4j, Amazon Neptune, TigerGraph — but AGE has a unique advantage for the modern data platform — it runs inside PostgreSQL.

We've recently seen customers increasingly using Apache AGE for a couple of reasons:

  1. No data movement: Your Iceberg tables and your graph live in the same database. You don't extract, transform and load (ETL) data out of your lake into a separate graph database, keep it in sync and mainta
[...]

All Your GUCs in a Row: cluster_name
Posted by Christophe Pettus in pgExperts on 2026-05-27 at 01:00
cluster_name looks like a cosmetic label for process listings, but on a standby it silently becomes the name your primary uses to verify synchronous…

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.