Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFHJu-0007S2-9W for pgsql-hackers@arkaria.postgresql.org; Mon, 29 May 2017 09:50:38 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dFHJt-0005N4-SU for pgsql-hackers@arkaria.postgresql.org; Mon, 29 May 2017 09:50:37 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dFHJt-0005Mv-49 for pgsql-hackers@postgresql.org; Mon, 29 May 2017 09:50:37 +0000 Received: from mail-pg0-x234.google.com ([2607:f8b0:400e:c05::234]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dFHJp-0003xy-V8 for pgsql-hackers@postgresql.org; Mon, 29 May 2017 09:50:35 +0000 Received: by mail-pg0-x234.google.com with SMTP id 8so20922632pgc.2 for ; Mon, 29 May 2017 02:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=114Wwi/eB92UzH2+ESmadSQMFl1pX/XaGNkeX8OB9R8=; b=f5eAa2HxLJ8b5WasQ9/lpdh3ka43Dsz51cGkQXJY3OuisUm4KRlgaN9ufloA7VVDUg oSednbZg2zkF8Gpb3l9Gyj06XZ33vLrj6eR+qEPstL0YrAXIAJlFimXea5ltXkB0ZiNB XTaiVuKbzOVfsDHv/KbY+gJtpcXazksa9iI7eU2rCagf30VcZvEPYCMzIQrC0477Lv6S zkW+tTEkJuWVkMZKYFp9gstA2wwnS4XUk+Fgan+OD+GdwI+NwHCiT/pMWEnm6Y6UXMF0 +3f1hFi6pVM65SWmitEDz+P1iQUcqH0optKEga2SJW87vkmtxqMPCQqwBLqaY1tM82SN 0f+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=114Wwi/eB92UzH2+ESmadSQMFl1pX/XaGNkeX8OB9R8=; b=c0dEehAZwBqkIxC1IT6G/ERjEujNRFBueWyhCphOc71DL0xIfOhmLY+uTT3wPX+eE0 FEHhvXQNe5NG9HlJGRM56fJUOI1t0P1m0mCW6BVRh0mlp6S1DqYk3DhnIckZwrI/tU6p diJuhvOey6oZ4sq4yRay48dwlOY2O4GT9wUMWTPTcYpY8QzzvGVIv0rkOmeBNEYsMr0a LATUDC35GgRk1NpiasXD93WJX5PBiZJjiCW0NfgBelHiCXFUB1cCRbILx3KbS3lh8ldI r8L0H67R/f5nR951dShrAsoG5tuIFxzcixfLre9cwta5x/GcUo8HXjlfvzzpYB1dZ/hb 8QIQ== X-Gm-Message-State: AODbwcCJHdpAHjEqcMMqqMfEw5+jc+PMScFxfv8Kk8cZ6Nn//aXXgtYo Q9ib+C9h7bwp+u9ZpVGxcng9wMUDNKvASmeP6qigQVUUmRFslqQkkkjXfWT3z/UMmwvJZKddulQ Nhtud5Zgsw6td66xkOp0q1D66V3bXKnHFpKdh6O67p78VFLiS/MpdYZYXYkSW263A+hnlhto= X-Received: by 10.84.218.134 with SMTP id r6mr22913545pli.190.1496051432900; Mon, 29 May 2017 02:50:32 -0700 (PDT) Received: from localhost.localdomain ([59.162.78.200]) by smtp.gmail.com with ESMTPSA id a87sm17027998pfj.50.2017.05.29.02.50.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 02:50:32 -0700 (PDT) Subject: Re: pg_resetwal is broken if run from v10 against older version of PG data directory To: Amit Kapila References: Cc: PostgreSQL-development From: tushar Message-ID: Date: Mon, 29 May 2017 15:20:29 +0530 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 05/29/2017 03:10 PM, Amit Kapila wrote: > What makes you think above is a valid usage and should > pass? with earlier versions ,for instance - v.96 v/s v9.5 ,pg_resetwal was giving pg_control values . Installed v9.6 and v9.5 and run pg_resetwal of v9.6 against data directory of v9.5. [centos@centos-cpula ~]$ /tmp/pg9.6/bin/pg_resetxlog -D /tmp/pg9.5/bin/data/ pg_resetxlog: pg_control exists but is broken or unknown version; ignoring it Guessed pg_control values: pg_control version number: 960 Catalog version number: 201608131 Database system identifier: 6425491233437069295 Latest checkpoint's TimeLineID: 1 Latest checkpoint's full_page_writes: off Latest checkpoint's NextXID: 0:3 Latest checkpoint's NextOID: 10000 Latest checkpoint's NextMultiXactId: 1 Latest checkpoint's NextMultiOffset: 0 Latest checkpoint's oldestXID: 3 Latest checkpoint's oldestXID's DB: 0 Latest checkpoint's oldestActiveXID: 0 Latest checkpoint's oldestMultiXid: 1 Latest checkpoint's oldestMulti's DB: 0 Latest checkpoint's oldestCommitTsXid:0 Latest checkpoint's newestCommitTsXid:0 Maximum data alignment: 8 Database block size: 8192 Blocks per segment of large relation: 131072 WAL block size: 8192 Bytes per WAL segment: 16777216 Maximum length of identifiers: 64 Maximum columns in an index: 32 Maximum size of a TOAST chunk: 1996 Size of a large-object chunk: 2048 Date/time type storage: 64-bit integers Float4 argument passing: by value Float8 argument passing: by value Data page checksum version: 0 Values to be changed: First log segment after reset: 000000010000000000000002 If these values seem acceptable, use -f to force reset. [centos@centos-cpula ~]$ -- regards,tushar EnterpriseDB https://www.enterprisedb.com/ The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers