Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1exb97-0008Pz-Hi for pgsql-admin@arkaria.postgresql.org; Sun, 18 Mar 2018 16:26:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1exb96-0007UA-AH for pgsql-admin@arkaria.postgresql.org; Sun, 18 Mar 2018 16:26:56 +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.89) (envelope-from ) id 1exb95-0007Tz-TY for pgsql-admin@lists.postgresql.org; Sun, 18 Mar 2018 16:26:56 +0000 Received: from sonic317-34.consmr.mail.ne1.yahoo.com ([66.163.184.45]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1exb93-0003eN-D0 for pgsql-admin@postgresql.org; Sun, 18 Mar 2018 16:26:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1521390411; bh=GHoUBrF82s7eFLkqKXMo7rkjg/GZLOEf9VYdRZP4vKs=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=GDzf76JTG5t11p+x8JUdeOoJp6YsBAbtQHhxNO7xVzQP/9gkTACweWfeYFCjvbHHB6c84jrM6VkgdupqlVZxIkm8jo5h0TZvQ9jxHYvOdEYIlHgM6oiibqpxEAkaaarCGSJlDiuFVXctA5YDPpIDYFqktvmFVjCsVAEzSIzluetTAXSupEw9KPjSdMYzsuioP4XL0ZD7FkGyy6DV1MyhoHrqbhEGFcO+4RJDnZff2pINvskNmXFySKVjeuiiQHTTmYNNMzhL3bxy1Nnx55LZYVY0ztoNtVQrb+7bVpZvHUPhB4S3bRMvCX75cwnEauYo4J8xi1BEHCbfH7dXecrWyA== X-YMail-OSG: r81J_AEVM1lT5KGi1yV9UFkcbPww0ysZqsrrYV3HiNcxxOusI7WMs0gAsmuXJXP k7AuGfG0NNvMr1XuKP27_3dZRMV.sVGkejDNCdNWO5g25mpSXOIYQnoRxeSfQzaaIEQaClMkn7F5 GYxCdgfaNB4.nqjMYEPbP62bAWDbfF4co4ZZGjil.dJjWgXEqttWfF5NKGMtFlGI0lAMdFNKXkEr 4dO_RF356EtmlMk8xcPKP6fZkdiDhnqxjdUVz0snP3jQKFLvUhCi.YkCS843eRhribZtwxg.gJf7 XOjezt8ljKlj6ewNKppJwdXVLkLgomGKLwROr2h6a1kSwPU8Z2Xk.kdOcq2QktFsn4a3Vf2BP7M4 FL3whdNNZLIJcIup.b0rs0EeZSKAMvMGY3RFBQKaduFzmqgA_RfUPfeUXAsZZdjFaIOjRbY.PpDB Qb4FyDl3t575SiFfP_cC31vj7SB3PC776c9uJ8ymOX83Mq5FBjcH7pHLrOzlQxnjxJ3YtaOcEbvx LF0QMM3qraKenFxXNsxcATj36I8e9XWphvg9l.JXTtgddUww7exQuo4wFsoF6HLI0BQ04P3liBjN eV.zdKco_5JwWCI3fSC9C Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Sun, 18 Mar 2018 16:26:51 +0000 Received: from sonic307-11.consmr.mail.ne1.yahoo.com (EHLO sonic307-11.consmr.mail.ne1.yahoo.com) ([66.163.190.34]) by smtp402.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ea58f64d422a3e9a6bcbafa7a01bcfe2; Sun, 18 Mar 2018 16:26:48 +0000 (UTC) X-YMail-OSG: DfUb9LQVM1nID.U5ZVssNGj9Xcosvp1aUpbZSGaTo5GaO.As3PJn11R2SyYSuYD sb0Ays4ruaRITMXnIovlw_w1RVss.M4ufHJHa6X99P2pBAha09lZSteumEfhTs1ontrsWAlLtOKB q1H9ZUkoUSvuvi6QAlqvr4rJGkE3FlVpnGdA9G5qgj4gBziEHkHqlJ_wmsnpgFYEJt7z2pOCssfr 7bfOhvi38r9tSXTUz6UX7jQYeI13qg2.A2uPXte19pD1vtOz9Z1Lu5suUcPE2mQvsGu2ezGYSGKo BImtc3v0VNN9dz2czCziMP3SE5IjN0kBE84881sF4JIJr.lnQNHCDky1_FPhm769TalahEoGXdWX TVi7pDxNXVClA4TQCnZR4VouxNDpbiIUek_fK5ZO1rMVp6iViuOoWyGWHNCliIWrH6DT4wD4cOMG ZjvVVEImmUT0whUAJP4Q1W927cVzgljH96HgZ1U.dZGsS8YVQNb.yrI9aUHfU.EgD4JFtbubHcg- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Sun, 18 Mar 2018 16:26:48 +0000 Date: Sun, 18 Mar 2018 16:26:42 +0000 (UTC) From: Bimal Reply-To: Bimal To: pgsql-admin@postgresql.org, Jerry Sievers Message-ID: <1195397079.2731184.1521390402043@mail.yahoo.com> In-Reply-To: <87a7v9rzpe.fsf@jsievers.enova.com> References: <87a7v9rzpe.fsf@jsievers.enova.com> Subject: Re: Wal fetching standby refuses to promote MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2731183_558742605.1521390402041" X-Mailer: WebService/1.1.11588 YMailNorrin Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 OPR/51.0.2830.55 Content-Length: 5414 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------=_Part_2731183_558742605.1521390402041 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You can try to add the trigger file in recovery.conf and perform a promote= . Never tried but should work.=C2=A0 On Thursday, March 15, 2018, 10:56:= 06 AM PDT, Jerry Sievers wrote: =20 =20 This was an atomic snapshot put in recovery and happily reading WALs from the repo. It's consistent and allows read-only querying.=C2=A0 It's replayed a few da= ys worth of WALs and was previously running with a recovery_target_xid =3D $some-xid which apparently was never hit and/or aborted. It would not promote then, after pg_ctl promote.=C2=A0 The 'promote' file d= id get created in pgdata. Now it's running again with recovery.conf that contains just... standby_mode =3D on restore_command =3D 'cp /somedir/%f %p' Still it fails to respond to the issuance of a promote. There is no trigger file config's in recovery.conf and we have never needed to do same since pg_ctl promote usually works. Any idea what's causing this? Thanks =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 version=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=20 ---------------------------------------------------------------------------= -------------------------------------- PostgreSQL 9.6.6 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ub= untu1~16.04.4) 5.4.0 20160609, 64-bit (1 row) --=20 Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@comcast.net p: 312.241.7800 =20 ------=_Part_2731183_558742605.1521390402041 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You can try to add the trigger file in recovery.conf and p= erform a promote. Never tried but should work. 
=20
=20
On Thursday, March 15, 2018, 10:56:06 AM PDT, Jerry= Sievers <gsievers19@comcast.net> wrote:


This was an atomic snapshot put i= n recovery and happily reading WALs
from the repo= .

It's consistent and = allows read-only querying.  It's replayed a few days
worth of WALs and was previously running with a recovery_target_xi= d =3D
$some-xid which apparently was never hit an= d/or aborted.

It would= not promote then, after pg_ctl promote.  The 'promote' file did
get created in pgdata.

<= /div>
Now it's running again with recovery.conf that contai= ns just...

standby_mod= e =3D on
restore_command =3D 'cp /somedir/%f %p'<= br>

Still it fails to resp= ond to the issuance of a promote.

There is no trigger file config's in recovery.conf and we have = never
needed to do same since pg_ctl promote usua= lly works.

Any idea wh= at's causing this?

Tha= nks

    &nbs= p;                     &n= bsp;                     =     version              &nbs= p;                     &n= bsp;              
------------------------------------------------------------------= -----------------------------------------------
= PostgreSQL 9.6.6 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubu= ntu1~16.04.4) 5.4.0 20160609, 64-bit
(1 row)
<= /div>


--
Jerry Sievers
Post= gres DBA/Development Consulting
= p: 312.241.7800

------=_Part_2731183_558742605.1521390402041--