On Mon, May 29, 2017 at 9:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
>
Yeah, I was wrong in suggesting to try to make it work. An explicit
error is a better way to deal with this.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
