Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: cf/6053~1
Choose a base ref
...
head repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: cf/6053
Choose a head ref
  • 2 commits
  • 9 files changed
  • 2 contributors

Commits on Oct 14, 2025

  1. Report size of reorder buffer contents 

    pg_stat_replication_slots reports cumulative statistics about spilled or
streamed transactions. It helps to know that whether the logical
decoding work memory is sufficient or not to hold all the changes. This
statistics does not give an idea about the total size of changes
belonging to the transactions tracked by the reorder buffer at a given
point in time. That is important to set logical decoding work memory
size so as to make use of memory, (in case spilled transactions) disk
and (in case of streamed transactions) resources on downstream
optimally.

This patch reports total size of the reorder buffer contents through
pg_stat_replication view. The size includes the contents in the memory,
spilled to the disk or sent downstream as part of an unfinished streamed
transaction.  Effectively it counts for size of all changes belonging
the transactions that are currently active in the reorder buffer. The
trendline of total reorder buffer size should help user set
logical_decoding_work_mem after considering various trade-offs.

It's arguable whether the count should be reported in
pg_stat_replication_slots or pg_stat_replication.
pg_stat_replication_slot covers all replication slots, in turn covering
wal senders as well as backends using replication slots e.g. clients
receiving logical changes via SQL callable functions. But it is a
cumulative statistics view and size of reorder buffer is a point in time
statistics. Such statistics are covered by
pg_stat_replication, which doesn't report statistics for client backends
receiving logical changes via a SQL callable function.
pg_stat_replication_slot statistics are updated at stragegic events
during logical decoding. Updating reorder buffer size at those strategic
points may not always suffice; it will not give the accurate value at
the time when the view is queried. pg_stat_replication fetches the real
time state of wal sender process and thus will report reorder buffer
size more accurately. But user may miss strategic events when sampling
pg_stat_replication.

Any serious user of logical replication who is looking for optimally
sizing logical_decoding_work_mem better be using a WAL sender. Thus
pg_stat_replication makes more sense.

Author: Ashutosh Bapat
    @ashutosh-bapat
    ashutosh-bapat authored and Commitfest Bot committed Oct 14, 2025
    Configuration menu
    Copy the full SHA
    98de35d View commit details
    Browse the repository at this point in the history

  2. [CF 6053] Report reorder buffer size 

    This branch was automatically generated by a robot using patches from an
email thread registered at:

https://commitfest.postgresql.org/patch/6053

The branch will be overwritten each time a new patch version is posted to
the thread, and also periodically to check for bitrot caused by changes
on the master branch.

Patch(es): https://www.postgresql.org/message-id/CAExHW5sX4a4GEMo99wcPALHPG9XM+-3ovAyPJ=ZnZAA=ux_EVw@mail.gmail.com
Author(s): Ashutosh Bapat
    Commitfest Bot committed Oct 14, 2025
    Configuration menu
    Copy the full SHA
    2ff32ac View commit details
    Browse the repository at this point in the history
Loading