PostgreSQL 13.4 fixes a planner path that could expose server memory

A query planner must preserve the meaning of intermediate rows while deciding how to execute a statement. PostgreSQL 13.4 repairs a case where stacking two projection paths could produce an incorrect plan. The consequences extend beyond a wrong answer or crash. A specially constructed query can expose arbitrary bytes of server memory.

The August 12 announcement identifies that flaw as CVE-2021-3677, affecting PostgreSQL 11 through 13. It accompanies releases 13.4, 12.8, 11.13, 10.18 and 9.6.23, as well as PostgreSQL 14 Beta 3. The announcement distinguishes the supported-branch maintenance updates from the continuing beta program.

I use PostgreSQL's plan visibility as a starting point for understanding query behavior. This defect concerns whether the planner constructs a valid execution strategy in the first place. A plan that appears to answer an ordinary SQL request still has to maintain the internal relationships on which safe execution depends.

Repeated projection breaks an internal assumption

The 13.4 release notes describe two ProjectionPaths stacked on top of each other. PostgreSQL could create an incorrect plan for that arrangement. Tom Lane receives credit for the fix.

The only known trigger involves parallel sort operations. The notes explicitly leave open the possibility of other instances. That distinction separates the known way to reach the defect from a complete characterization of every query shape that might reach it.

Crashes and incorrect results are possible consequences. The security announcement adds that authenticated users can complete the memory-disclosure attack under the default configuration. Unlike vulnerabilities that require a specially prepared table, this attack does not require object-creation privileges.

That difference affects privilege-based exposure analysis. Removing permission to create tables does not prevent the reported query from reaching the vulnerable planning path. A role allowed to submit SQL can matter even if it cannot establish new schema objects.

The advisory identifies max_worker_processes set to zero as making known versions of the attack infeasible. It immediately qualifies that statement because undiscovered variants might not depend on the setting. The parameter therefore describes a limit on the known attack, not a guarantee that the planner flaw becomes unreachable.

The practical security repair is the updated server code. Treating a parallel-worker setting as a complete substitute would discard the advisory's qualification. It would also conflate the observed triggering query with the defective planner behavior that the patch corrects.

Snapshot restoration has its own failure mode

Another fix restores the Portal-level snapshot after COMMIT or ROLLBACK inside a procedure. The release notes connect the missing snapshot with failures when fetching a toasted value immediately after transaction control. Reported messages include missing chunks and the absence of known snapshots.

This is a distinct issue from the security flaw. It concerns the execution context needed to read a value after a procedure changes transactions. The fix explains why a storage-related error message can originate in missing snapshot state rather than the particular stored value being corrupt.

The notes also state a responsibility for extensions that execute SQL outside a Portal. Such extensions must ensure an outer snapshot exists. Previously, omitting it might work or fail. After this change, the unsupported situation consistently produces an error about executing SQL without an outer snapshot or Portal.

A consistent error is operationally useful because it identifies the missing prerequisite. It also changes how an extension might experience an update. Code that happened to work without the required snapshot can now fail predictably until it establishes the correct execution context.

I consider this kind of release-note detail essential when PostgreSQL hosts extensions. The database's extension interface enables substantial functionality, but an extension still has obligations to the engine. A maintenance release can make an existing obligation enforceable without introducing a new application feature.

Recovery cannot stop before an irreversible operation

The update also changes the minimum recovery point when replaying an abort record truncates a file. The release notes explain the reason directly. File truncation is irreversible, so recovery cannot safely stop before the record that caused it.

The corresponding commit case had already been handled. The abort case was overlooked. That difference matters because an aborted transaction can still drive a physical storage operation during recovery. Transaction outcome alone does not determine whether replay has crossed a point that cannot be undone.

This fix aligns the allowed recovery endpoint with the physical changes already made. Once the file has been truncated, an earlier apparent endpoint would no longer describe the available storage state. The bookkeeping has to preserve that fact.

Another recovery-related fix advances the oldest-required-WAL horizon after a replication slot is invalidated. If every slot became invalid, the horizon could stop moving. The notes connect that failure with the server eventually exhausting its WAL storage space.

Both corrections concern state that determines what the server may discard or where recovery may stop. They have different mechanisms and symptoms. Grouping them only as replication improvements would hide the precise conditions an operator needs to understand.

Observation also becomes more accurate

WAL sender processes now report their latest replication command in pg_stat_activity. Previously, the displayed activity could remain the latest SQL command while the process had moved on to a replication operation. The change makes the observation correspond to the process's current class of work.

The update also repairs pending_restart reporting when a relevant configuration entry is removed. The setting already reported a changed entry that required restart, but removing the entry did not receive equivalent treatment. An absent line can change the effective configuration just as an edited line can.

These changes do not repair CVE-2021-3677, but they improve the information available while operating the updated database. Their release-note descriptions identify exactly which formerly misleading observations change.

A 13.x installation requires no dump and restore for 13.4. Anyone upgrading from before 13.2 must also read that release's migration instructions. The same announcement keeps PostgreSQL 14 Beta 3 under a separate major-style upgrade procedure and continues to advise against beta production use.