PostgreSQL logical replication: slots, WAL and pgoutput

PostgreSQL logical replication sits on WAL, logical decoding, and replication slots. Public discussions often center on the built-in pgoutput plugin because that is what native logical replication uses. That is useful engineering context, and it is separate from what any given CDC product plugs into.

This article covers the shared PostgreSQL mechanics (WAL, slots, pgoutput, bloat, recovery), then states clearly what Gluesync uses for PostgreSQL CDC: the wal2json logical decoding plugin, as documented in the Gluesync WAL CDC guide.

WAL and logical decoding (platform basics)

Every committed change is written to the Write-Ahead Log. Logical decoding plugins turn WAL records into a logical change stream for subscribers.

Common building blocks:

• WAL: durable redo, retained long enough for slow consumers
• Logical decoding: a plugin transforms WAL into a message format
• Replication slots: server-side bookmarks, so WAL is not recycled before the consumer reads it
• pgoutput: PostgreSQL’s built-in output plugin for native logical replication publications/subscriptions
• wal2json (and others): alternative decoding plugins with JSON-oriented message shapes

Understanding pgoutput helps you reason about publications, REPLICA IDENTITY, and slot behavior in general PostgreSQL estates. It does not imply every CDC tool consumes pgoutput.

Replication slots: power and foot-guns

Slots prevent WAL removal until the confirmed flush LSN advances. That protects catch-up, and it causes WAL bloat if a consumer dies or stalls.

Operational checklist:

• Monitor slot lag and retained WAL size
• Alert before disk fills
• Plan what happens when you drop or recreate a slot (resync vs resume)
• Treat checkpoint and restart as first-class tests, not afterthoughts

Schema evolution

Logical streams break or surprise you when:

• Tables lack a suitable replica identity for updates/deletes
• Columns are added/dropped/renamed while consumers assume a fixed schema
• Publications (for native logical replication) omit new tables

Any connector, AI-built or commercial, needs an explicit DDL policy.

What Gluesync uses for PostgreSQL CDC

Gluesync’s PostgreSQL change-data-capture path is documented around WAL logical decoding with the wal2json plugin and wal2json message formats, not as a pgoutput consumer.

Product docs:

• PostgreSQL CDC (WAL / wal2json)
• PostgreSQL agent intro

When you evaluate Gluesync, validate wal2json availability on your PostgreSQL version, slot privileges, and WAL retention. A pgoutput publication and subscription setup only matters if you are comparing against native logical replication separately.

wal2json and the output_plugin_libraries allowlist

The PostgreSQL minor releases 18.6, 17.11, 16.15, 15.19 and 14.24, published on 13 August 2026, fix CVE-2026-6471 by adding a server parameter, output_plugin_libraries. It lists the libraries replication clients may use as logical output plugins, and every other request is refused, for superusers too. The default is 'pgoutput, test_decoding', the two plugins shipped with PostgreSQL.

wal2json is not on that default list. On an updated server, Gluesync PostgreSQL sources fail with SQLSTATE 42501 (library "wal2json" may not be used as an output plugin) until wal2json is added. The error looks like a missing grant, but it is not one. The refusal appears at the first PostgreSQL restart after the package update, because a replication stream that is already open survives the upgrade. Slots that already existed stop advancing and keep retaining WAL, so watch pg_wal until it is fixed.

Extend the list, do not replace it: keep pgoutput, test_decoding and any plugin returned by SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;. In postgresql.conf the value is one comma-separated string:

output_plugin_libraries = 'pgoutput, test_decoding, wal2json'

With ALTER SYSTEM, each plugin is its own string literal. A single quoted, comma-separated string is stored as one list entry and wal2json is still refused:

ALTER SYSTEM RESET output_plugin_libraries;
ALTER SYSTEM SET output_plugin_libraries = 'pgoutput', 'test_decoding', 'wal2json';
SELECT pg_reload_conf();

A configuration reload is enough, no restart needed. Once wal2json is allowed, entities that were already in CDC resume from where they stopped. Pipelines created after the update never got a slot, so they need a snapshot to realign the target.

References: Gluesync PostgreSQL troubleshooting, PostgreSQL: output_plugin_libraries and the PostgreSQL 17.11 release notes.

Build vs buy

Dimension	AI-generated / custom	Gluesync PostgreSQL CDC
Decoding plugin	You pick and maintain (pgoutput, wal2json, other)	Documented wal2json WAL CDC path
Slot lifecycle	Custom create/drop/monitor	Agent + ops guidance in docs
WAL bloat	Your alerts and runbooks	Still your PostgreSQL ops: the agent reads through replication slots, so monitor their retained WAL
Message format	Ad-hoc parsers	wal2json formats as per Gluesync docs
Schema / restart	DIY	Agent resumes CDC from its replication slot; target schema inferred and managed by Gluesync by default

Build if CDC decoding is core IP and you will staff Postgres replication expertise. Buy if you want a maintained wal2json-based capture path into your targets.

Latency note

Gluesync is positioned for low end-to-end latency: molo17.com lists under 50ms end to end. Real lag still depends on WAL volume, slot health, network, and apply topology, so treat under 50ms as platform positioning, not a measured guarantee for every deployment. Measure on your cluster.

FAQs

Does Gluesync use pgoutput?

No. Gluesync’s documented PostgreSQL CDC agent uses wal2json for logical decoding. pgoutput remains relevant as general PostgreSQL logical replication knowledge and for native pub/sub comparisons.

Why does pgoutput matter if Gluesync uses wal2json?

Because pgoutput is what native PostgreSQL publications and subscriptions use, so most PostgreSQL documentation explains slots and logical decoding through it. The slot mechanics are the same whichever plugin decodes the stream: WAL retention, restart_lsn, confirmed_flush_lsn, replica identity. The plugin decides the message format and, on PostgreSQL releases from August 2026 onward, whether the server allows it at all.

What is the main production risk with slots?

A stuck consumer holding a slot → unbounded WAL retention → disk pressure. Monitor lag and retained bytes.

Can AI generate a safe slot consumer?

It can write a reader. Production still needs slot monitoring, wal2json (or your chosen plugin) version quirks, restart from LSN, and DDL policy.

Next steps

• WAL CDC / wal2json docs
• PostgreSQL intro
• PostgreSQL troubleshooting: wal2json and output_plugin_libraries
• Start a 30-day Gluesync trial against your PostgreSQL build, with wal2json installed and allowed in output_plugin_libraries.