Amit Kapila <amit.kapila16@gmail.com> writes:
> I think this happens due to commit
> f82ec32ac30ae7e3ec7c84067192535b2ff8ec0e which renames pg_xlog to
> pg_wal. It does take care of making some of the modules like
> pg_basebackup to understand both old and new directory structures, but
> not done for all the modules.
check
> I think we should make similar changes
> in pg_resetwal or at the very least update the docs to indicate
> pg_resetwal can give an error if used against pre-10 data directory.
I think it's just horribly dangerous to run any version of
pg_resetxlog/pg_resetwal against any major version other than its
own. If people have been doing what the OP tried to do, it's only
been sheerest luck if it didn't destroy their database beyond recall.
The result will certainly fail to start up, because both pg_control
and WAL page header versions will not match the server version. The
*best* case scenario is that redoing the reset with the correct version
of pg_resetxlog/pg_resetwal gets you out of that with no new damage
done. The worst case is pretty awful --- for instance, a truly
bullheaded user might try to get out of it by starting the newer server
version in the old DB, likely causing irrecoverable catalog corruption.
So we need to prevent this, not try to make it work. I don't think
we can insist on a version match in pg_control, because part of the
point of pg_resetxlog/pg_resetwal is to recover if pg_control is
unreadable. But I think we could look at PG_VERSION, which is only a
text file. In bad corruption scenarios, if that somehow got corrupted
(which seems unlikely since it's never written to post-initdb),
you could fill in the correct contents by hand and then
pg_resetxlog/pg_resetwal would run.
regards, tom lane
