Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXKPP-0006VX-8m for pgsql-admin@arkaria.postgresql.org; Fri, 05 Jan 2018 05:19:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXKPN-0003u1-BX for pgsql-admin@arkaria.postgresql.org; Fri, 05 Jan 2018 05:19:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eXKPM-0003tr-KG for pgsql-admin@lists.postgresql.org; Fri, 05 Jan 2018 05:19:09 +0000 Received: from resqmta-po-05v.sys.comcast.net ([2001:558:fe16:19:96:114:154:164]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eXKPH-0007tM-RL for pgsql-admin@postgresql.org; Fri, 05 Jan 2018 05:19:07 +0000 Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-05v.sys.comcast.net with ESMTP id XKP3eKyuwAWmsXKPCez3gx; Fri, 05 Jan 2018 05:18:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1515129538; bh=nEsMqohUYC9FesjCBalDWFgba9kUAPNiElaDhXkD59M=; h=Received:Received:Received:From:To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=VfzJOYDXqC8WRNfcZdN8+xlJ3uUg1fflOZzYHMhLFL2DVntjmT7jFxKRBAD339HAV YDiNJWnxuInL6y+FLqoJU2/34BO1zrU8FcPWPYEhQnpU1ZjzefVrbHMP1YBCeUK5eJ JRJVnnH4Ewgs0uWXj4DEQ8wGZ4kgP/W8AvHCjIQotATplZ8b+pMXI/DpmZyu4G3j8j DPtZNFv1nZW7vCAZRVju5FAO39r9STO5CWVJhPmuwN1PlATTm8htAhXFDpChGMf4+X pS9vBDRAwTVSjN/03Ldz1B5OIBAGr9AJkGom4PX6rathsWm1SFZdEpaJB8gTpbjhCC nNkw1Nh+Ai5ZA== Received: from jsievers.comcast.net ([12.30.159.20]) by resomta-po-18v.sys.comcast.net with SMTP id XKP3equgYp78pXKP6elfSM; Fri, 05 Jan 2018 05:18:56 +0000 Received: from jsievers.enova.com (localhost [127.0.0.1]) by jsievers.comcast.net (Postfix) with ESMTP id 7D0BC26005E for ; Thu, 4 Jan 2018 23:18:49 -0600 (CST) From: Jerry Sievers To: pgsql-admin@postgresql.org Subject: pg_rewind: confused about recovery.conf/restore_command Date: Thu, 04 Jan 2018 23:18:49 -0600 Message-ID: <87fu7khohy.fsf@jsievers.enova.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-CMAE-Envelope: MS4wfCEJ9cQJ2ebd/dDh24aN0yrn5CilnDYlKngWcL2xksJs7ZtcFXUVfpkA/OJdSCtbaZnlMv3ekxt2NbOp3a7bGr1mct/hSY6KeUjELmTqt0LIPuvluWcd FmaBUDhCxcFZ+TV1vNIlPGTL3xW/e9LabLnJlKSrKoFBSFl9oAYvCtH9GoLpsf+7piwMpFxRo7vY1Q== List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Pg 9.6.6 on Ubuntu. I have a master and a streamer/standby. Streamer runs wal_log_hints=on, archive_mode=always, archive_command='send it to some repo'. Promote streamer and make some changes to it. Halt and run pg_rewind as per my understanding of the docs. Rewind immediately errors out due to missing wal segments on target system (streamer). Same target has a recovery.conf at this point w/restore_command that knows how to fetch wal segment from 'some repo'. ISTM rewind is supposed to use it to fetch wals. Success in same attempt if streamer has archive_command='' thus retaining wals inside data directory. Running pg_rewind with --progress --debug shows no indication that it's trying to use restore command and in fact chmod 0 on the recovery.conf file makes no difference either. Am I dreaming that this should work? :-) Thanks -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@comcast.net p: 312.241.7800