Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers