PG_WALDUMP(1)

🌸 PG_WALDUMP(1) 🌸

okay bestie, so this is a page straight out of the PostgreSQL 15.19 Documentation and it's all about pg_waldump, which is genuinely one of my fave little detective tools, no cap 💅

---

✨ NAME ✨

pg_waldump — displays a human-readable rendering of the write-ahead log of a PostgreSQL database cluster 🎀

---

🦋 SYNOPSIS 🦋

pg_waldump [option...] [startseg [endseg]]

---

💖 DESCRIPTION 💖

So pg_waldump displays the write-ahead log (WAL), and honestly it's mainly useful for debugging or educational purposes — think of it as reading the diary the database writes to itself 🫶

okay important thing, bestie: this utility can only be run by the user who installed the server, because it requires read-only access to the data directory. that's the vibe check, and it's non-negotiable 🙈

---

👑 OPTIONS 👑

These command-line options control the location and format of the output, and there's a lot of them, so buckle up 🌈

• startseg — start reading at the specified log segment file. This implicitly determines the path in which files will be searched for, and the timeline to use. like, it just knows ✨
• endseg — stop after reading the specified log segment file.
• -b, --bkp-details — output detailed information about backup blocks. all the receipts, iykyk 💅
• *-B *block, --block=block — only display records that modify the given block. The relation must also be provided with --relation or -R. you can't just go naming blocks with no relation, that's not how we do things 😭
• *-e *end, --end=end — stop reading at the specified WAL location, instead of reading to the end of the log stream. boundaries, we love them 🎀
• -f, --follow — after reaching the end of valid WAL, keep polling once per second for new WAL to appear. she's patient, she's loyal, she's refreshing 🧚
• *-F *fork, --fork=fork — if provided, only display records that modify blocks in the given fork. The valid values are main for the main fork, fsm for the free space map, vm for the visibility map, and init for the init fork. pick your fighter ⭐
• *-n *limit, --limit=limit — display the specified number of records, then stop. we're leaving before it gets weird 💀
• *-p *path, --path=path — specifies a directory to search for log segment files or a directory with a pg_wal subdirectory that contains such files. The default is to search in the current directory, the pg_wal subdirectory of the current directory, and the pg_wal subdirectory of PGDATA. she'll go looking for you, don't worry 🦋
• -q, --quiet — do not print any output, except for errors. This option can be useful when you want to know whether a range of WAL records can be successfully parsed but don't care about the record contents. lowkey the "did it parse tho" option 👑
• *-r *rmgr, --rmgr=rmgr — only display records generated by the specified resource manager. You can specify the option multiple times to select multiple resource managers. If list is passed as name, print a list of valid resource manager names, and exit. one rmgr is cute, multiple rmgrs is a party 🎉

Extensions may define custom resource managers, but pg_waldump does not load the extension module and therefore does not recognize custom resource managers by name. Instead, you can specify the custom resource managers as custom### where ### is the three-digit resource manager ID. Names of this form will always be considered valid. custom names stay iconic, fr fr 💜

• *-R *tblspc/db/rel, --relation=tblspc/db/rel — only display records that modify blocks in the given relation. The relation is specified with tablespace OID, database OID, and relfilenode separated by slashes, for example 1234/12345/12345. This is the same format used for relations in the program's output. slashes slay 🌸
• *-s *start, --start=start — WAL location at which to start reading. The default is to start reading the first valid log record found in the earliest file found. start at the very beginning, a very good place to start 🎀
• *-t *timeline, --timeline=timeline — timeline from which to read log records. The default is to use the value in startseg, if that is specified; otherwise, the default is 1. different timelines, different multiverses 🌀
• -V, --version — print the pg_waldump version and exit. drop the version number and dip ✌️
• -w, --fullpage — only display records that include full page images. full page images only, she's picky 💅
• *-x *xid, --xid=xid — only display records marked with the given transaction ID. specific transaction energy 👑
• -z, --stats[=record] — display summary statistics (number and size of records and full-page images) instead of individual records. Optionally generate statistics per-record instead of per-rmgr. she's giving data analyst, she's giving dashboards 📊

If pg_waldump is terminated by signal SIGINT (Ctrl+C), the summary of the statistics computed is displayed up to the termination point. This operation is not supported on Windows. rip to the Windows girlies 😭

• -?, --help — show help about pg_waldump command line arguments, and exit. when in doubt, ask for help, bestie 🫶

---

🌈 ENVIRONMENT 🌈

• PGDATA — data directory; see also the -p option. this is where your data lives, treat her well 💖
• PG_COLOR — specifies whether to use color in diagnostic messages. Possible values are always, auto and never. yes, you can force the aesthetic 🎨

---

⭐ NOTES ⭐

can give wrong results when the server is running. like, she's trying her best, but a running server means the WAL is moving, and that's just not a stable relationship 😬

Only the specified timeline is displayed (or the default, if none is specified). Records in other timelines are ignored. we don't do multiverse crossovers here 🙅‍♀️

pg_waldump cannot read WAL files with suffix .partial. If those files need to be read, .partial suffix needs to be removed from the file name. so close and yet so far 💀

---

🧚 SEE ALSO 🧚

Section 30.6 — go read it, it's giving required reading ✨

---

and that's the whole page, bestie! mwah 💋

signing off with love: this was PostgreSQL 15.19, dated 2026 — PG_WALDUMP(1), no cap 🌸💖🎀