Thomas Munro <[email protected]> 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
