Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon

Hi Surya,

Thanks for the review.

On Tuesday, August 18th, 2026 at 4:38 PM, surya poondla <suryapoondla4(at)gmail(dot)com> wrote:

> 1. maintenance.sgml and system-views.sgml contradict each other on datid, and I feel maintenance.sgml is wrong.

I agree and have revised maintenance.sgml.

> 2. Would a column distinguishing the xid holder from xmin holders be worth adding?

Yes, and I added an xid column.

> 3. It would be worth adding a test for the case where a slot's effective_xmin is set while data.xmin is still invalid
> ...
> Conveniently the state is stable and ReplicationSlotRelease() only clears effective_xmin when the slot is released, so another session can
> compare the two views while the replication connection is held open.

I added the test, but CreateReplicationSlot() calls
ReplicationSlotRelease() directly, so the state is not stable without
a pre-existing transaction to block slot creation.

> - The recovery errhint() puts the function name inside the format string.

I fixed this too.

> - The xact_start assertion in the regression test compares the view's
> xact_start against pg_stat_activity.xact_start, which is where the view sources it, so it exercises the join rather than the value.

There is no independent source to compare against, so I kept the
assertion just to exercise the join.

In addition, I corrected these errors:

1. The datfrozenxid section recommended filtering by datid, but only
shared_xmin affects datfrozenxid, and shared_xmin operates across
databases.

2. Non-walsender backends not connected to a database only affect the
shared horizon, but v4 emitted their rows with non-null data_xmin and
catalog_xmin columns.

v5 is attached and applies to master f20c4278342.

--
Scott Ray