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/5908~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/5908
Choose a head ref
  • 4 commits
  • 8 files changed
  • 2 contributors

Commits on Aug 10, 2025

  1. Introduce feature to start WAL receiver eagerly 

    This commit introduces a new GUC wal_receiver_start_condition which can
enable the standby to start it's WAL receiver at an earlier stage. The
GUC will default to starting the WAL receiver after WAL from archives
and pg_wal have been exhausted, designated by the value 'exhaust'.
The value of 'startup' indicates that the WAL receiver will be started
immediately on standby startup. Finally, the value of 'consistency'
indicates that the server will start after the standby has replayed up
to the consistency point.

If 'startup' or 'consistency' is specified, the starting point for the
WAL receiver will always be the end of all locally available WAL in
pg_wal. The end is determined by finding the latest WAL segment in
pg_wal and then iterating to the earliest segment. The iteration is
terminated as soon as a valid WAL segment is found. Streaming can then
commence from the start of that segment.

Archiving from the restore command does not holds the control lock
and enabling XLogCtl->InstallXLogFileSegmentActive for wal reciever early start
will create a race condition with the checkpointer process as fixed in cc2c7d6.
Hence skipping early start of the wal receiver in case of archive recovery.

Co-authors: Sunil S<[email protected]>, Soumyadeep Chakraborty <[email protected]>, Ashwin Agrawal, Asim Praveen, Wu Hao, Konstantin Knizhnik
Discussion:https://www.postgresql.org/message-id/flat/CANXE4Tc3FNvZ_xAimempJWv_RH9pCvsZH7Yq93o1VuNLjUT-mQ%40mail.gmail.com
    @SunilS26
    SunilS26 authored and Commitfest Bot committed Aug 10, 2025
    Configuration menu
    Copy the full SHA
    7b61f7f View commit details
    Browse the repository at this point in the history

  2. Test WAL receiver early start upon reaching consistency 

    This test ensures that when a standby reaches consistency,
the WAL receiver starts immediately and begins streaming using the latest valid
 WAL segment already available on disk.
This behavior minimizes delay and avoids waiting for WAL file once all the
locally available WAL file is restored and helps in providing `HIGH AVAILABILITY`
incase of Primary crash/failure.

More it helps quicker recovery when `recovery_min_apply_delay` in large and saves
Primary from running out of space.

Co-authors: Sunil S<[email protected]>, Soumyadeep Chakraborty <[email protected]>, Ashwin Agrawal, Asim Praveen, Wu Hao, Konstantin Knizhnik
Discussion: https://www.postgresql.org/message-id/flat/CANXE4Tc3FNvZ_xAimempJWv_RH9pCvsZH7Yq93o1VuNLjUT-mQ%40mail.gmail.com
    @SunilS26
    SunilS26 authored and Commitfest Bot committed Aug 10, 2025
    Configuration menu
    Copy the full SHA
    873f171 View commit details
    Browse the repository at this point in the history

  3. Test archive recovery takes precedence over streaming 

    Since archive recovery is typically faster and more efficient than streaming,
initiating the WAL receiver early—before attempting recovery from archived WAL
files—is not ideal.
Furthermore, determining the correct starting point for streaming by examining
the last valid WAL segment restored from the archive adds complexity and potential risk.

Therefore, even when the configuration parameter wal_receiver_start_at is set to consistency,
archive recovery should take precedence, and the WAL receiver should only be
started after archive recovery is exhausted or deemed unavailable.

Co-authors: Sunil S<[email protected]>, Soumyadeep Chakraborty <[email protected]>, Ashwin Agrawal, Asim Praveen, Wu Hao, Konstantin Knizhnik
Discussion: https://www.postgresql.org/message-id/flat/CANXE4Tc3FNvZ_xAimempJWv_RH9pCvsZH7Yq93o1VuNLjUT-mQ%40mail.gmail.com
    @SunilS26
    SunilS26 authored and Commitfest Bot committed Aug 10, 2025
    Configuration menu
    Copy the full SHA
    775d166 View commit details
    Browse the repository at this point in the history

  4. [CF 5908] v7 - Unnecessary delay in streaming replication due to repl… 

    …ay lag

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

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

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/CAOG6S4_GYpUoEyijdommZRFXyH-M2yp8AEnmkwSuri_2LN7Ugw@mail.gmail.com
Author(s): Sunil S
    Commitfest Bot committed Aug 10, 2025
    Configuration menu
    Copy the full SHA
    4c36e31 View commit details
    Browse the repository at this point in the history
Loading