Analysis: Advance restart_lsn More Eagerly in LogicalConfirmReceivedLocation

Core Problem

This thread is a brief post-commit follow-up regarding a patch that was already pushed to PostgreSQL. The patch addresses how restart_lsn is advanced in the logical replication subsystem, specifically within the LogicalConfirmReceivedLocation() function.

Technical Background

In PostgreSQL's logical replication architecture, restart_lsn is a critical marker stored in replication slots that indicates the oldest WAL position from which decoding must restart if the slot is reactivated (e.g., after a crash or subscriber reconnection). If restart_lsn is not advanced promptly, WAL segments accumulate on disk because the system cannot recycle them — they might still be needed for logical decoding replay.

The function LogicalConfirmReceivedLocation() is called when a subscriber confirms it has received and applied changes up to a certain LSN. The original behavior was apparently conservative in advancing restart_lsn, only doing so under specific conditions (likely tied to transaction boundaries or catalog snapshot considerations). The patch makes this advancement more "eager" — meaning restart_lsn progresses forward more frequently, allowing WAL to be recycled sooner.

Why This Matters Architecturally

1. WAL disk space management: Stale restart_lsn values cause WAL bloat, which is one of the most common operational pain points with logical replication slots.
2. Crash recovery efficiency: A more current restart_lsn means less WAL to replay upon slot re-activation.
3. Slot invalidation avoidance: In newer PostgreSQL versions with max_slot_wal_keep_size, a lagging restart_lsn can trigger premature slot invalidation.

The Attribution Issue

The substantive content of this thread is purely procedural: Álvaro Herrera (the committer who pushed the patch) acknowledges that he failed to properly credit Chao Li as a co-author of the patch in the commit message. He references the original development thread where the patch was discussed.

Commit Message Best Practices

Álvaro provides guidance on commit message conventions:

• Discussion: trailer — links to the mailing list thread
• Author: trailer — credits patch authors (especially co-authors)
• Reviewed-by: trailer — credits reviewers

He notes that while he typically rewrites commit messages extensively before pushing, he preserves these attribution trailers. This is a common workflow among PostgreSQL committers who maintain high editorial standards for commit messages.

Key Observations

The actual technical discussion of the patch's design and implementation occurred in a separate thread (referenced via the message-id link). This thread serves only as a correction to the commit metadata. The patch itself was evidently non-controversial enough to be pushed without extended debate in this follow-up, suggesting either broad consensus was achieved in the original thread or the change was relatively straightforward.