pg_waldump --help claims that you run it like this:
Usage: pg_waldump [OPTION]... [STARTSEG [ENDSEG]]
And https://www.postgresql.org/docs/10/static/pgwaldump.html agrees.
Since square brackets indicate optional arguments, this sort of makes
it sound like running pg_waldump with no arguments ought to work. But
it doesn't:
$ pg_waldump
pg_waldump: no arguments specified
Try "pg_waldump --help" for more information.
If we removed the error check that displays "pg_waldump: no arguments
specified", then it would still fail, but with a more useful error
message:
$ pg_waldump --
pg_waldump: no start WAL location given
Try "pg_waldump --help" for more information.
That message ought to perhaps be changed to say that you specified
neither the start WAL location nor the start WAL file, but even as it
stands it's certainly better than "no arguments specified".
Another problem is that if the file name you pass to pg_waldump
doesn't happen to have a name that looks like a WAL file, it fails in
a completely ridiculous fashion:
$ pg_waldump /etc/passwd
pg_waldump: FATAL: could not find file "000000017C55C16F000000FF": No
such file or directory
The problem appears to be that fuzzy_open_file() successfully opens
the file and then invokes XLogFromFileName() on the filename.
XLogFromFileName() calls sscanf() on the file name without any error
checking, which I think results in leaving private.timeline
uninitialized and setting segno to whatever preexisting garbage was in
the log and segno variables declared inside XLogFromFileName(),
resulting in an attempt to find a more or less completely random file.
A slightly broader concern is whether we need to require the start
position at all. It seems like one could locate the WAL directory
using the existing logic, then search for the earliest file. It might
be a little unclear what "earliest" means when multiple timelines are
present, but I bet we could come up with some behavior that would be
convenient for most users. It would be quite handy to be able to run
this without arguments (or just with -z) and have it process all the
WAL files that you've got on hand.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company