I was under the impression that WAL segments files are normally generated before they are being written to and archived, and are continuously renamed and reused to save disk space. I was wondering if I safely assume that when restoring these unarchived WAL segments, they are renamed to match that of the database's current timeline?

Current WAL writing location Current pg_wal directory

All of the files from 00000004...13 to 00000004...19 previously had the timeline ID of 1 (00000001...13 to 00000001...19 respectively), and these were placed in the pg_wal directory before the restore process was executed.

Whenever an archive recovery completes, a new timeline is created to identify the series of WAL records generated after that recovery.

Since these WAL segments were generated in a previous timeline but were never written to, does this allow Postgres to rename those same WAL files to match that of the current timeline without any issues?

  • It is not clear what you are asking. Based on your screenshot, the files have already been renamed. Did you do that? Or did PostgreSQL do that, and you are asking whether that was a bug?
    – jjanes
    Feb 15, 2020 at 19:50
  • @jjanes Sorry for the delay! It seems as though PostgreSQL did that, and I was wondering if that was the intended behavior?
    – femonova
    Feb 29, 2020 at 16:58

1 Answer 1


According to the source code (assuming I'm looking at the correct location, Postgres will take an old WAL file and rename it based on the current timeline ID. According to this comment, timeline ID of old files are ignored -- basically, the assumption is that if you have files with LSN < current LSN, it doesn't matter if it's from another timeline: it's just "old" and can be recycled

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.