Re: pg_waldump: support decoding of WAL inside tarfile

Thomas Munro <thomas.munro@gmail.com> writes:
> This fails 100% of the time on my machine, even after e9d72348 and ff84efe4, eg:

> # Running: pg_waldump --path /tmp/D8WG1Sv2HE/pg_wal.tar --start
> 0/017A2610 --end 0/02093848
> [09:43:29.288](0.148s) not ok 104 - runs with path option and start
> and end locations: exit code 0
> [09:43:29.289](0.001s) #   Failed test 'runs with path option and
> start and end locations: exit code 0'
> #   at /home/tmunro/projects/postgresql/src/bin/pg_waldump/t/001_basic.pl
> line 402.
> [09:43:29.290](0.001s) not ok 105 - runs with path option and start
> and end locations: no stderr
> [09:43:29.291](0.001s) #   Failed test 'runs with path option and
> start and end locations: no stderr'
> #   at /home/tmunro/projects/postgresql/src/bin/pg_waldump/t/001_basic.pl
> line 402.
> [09:43:29.291](0.000s) #          got: 'pg_waldump: error: could not
> find WAL "000000010000000000000002" in archive "pg_wal.tar"
> # '

Huh.  What is your platform exactly?  Maybe more to the point,
what is the tar program you're using?

> Seems like it already stepped over 000000010000000000000002 earlier?
> Could it be a table-of-contents order dependency bug or something like
> that?

If you look at the TAP script, you'll see that it tries to randomize
the order of the entries in the tar file (see sub generate_archive).
So if that's the problem, it shouldn't reproduce 100%, and also we
should be seeing lots of freckles on the buildfarm.  We're not, so
there must be something off-the-beaten-track about your test
environment.

I'm certainly more than prepared to believe there's still bugs
lurking here, but we need to figure out why you're seeing it.

            regards, tom lane