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 1eoH4D-0006mY-Fi for pgsql-admin@arkaria.postgresql.org; Tue, 20 Feb 2018 23:11:21 +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 1eoH4C-0004Su-FT for pgsql-admin@arkaria.postgresql.org; Tue, 20 Feb 2018 23:11:20 +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 1eoH4B-0004SR-Jz for pgsql-admin@lists.postgresql.org; Tue, 20 Feb 2018 23:11:20 +0000 Received: from resqmta-po-01v.sys.comcast.net ([2001:558:fe16:19:96:114:154:160]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eoH48-0001Iv-Ti for pgsql-admin@lists.postgresql.org; Tue, 20 Feb 2018 23:11:18 +0000 Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-01v.sys.comcast.net with ESMTP id oH43eFDiNlwOeoH47e5qn9; Tue, 20 Feb 2018 23:11:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1519168275; bh=u7AsPRfgXWDmLE/o6GnrpQ67OjiTCKBTtbxODi6DnfI=; h=Received:Received:Received:From:To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Z+0DEuBNZR1QzY4EPLFFHCfjgc2n7zxxXhmajqN24UBVUfNjYIgeQIBI7lZmEcqzH bWp3Uv6Sh+vS3WoahSDeSZfMU2sYjRynnKLbsnGaCsJBac5MygJLl95HUd3H0uAZgi fbYBXWE4IzecZRpJw4w8YrBqFIam/4+2Kg/I4TUeuVjCbfeB7OozLpGJaavFPGArx5 JbUEM9IHUlnSz42Aj/xzec8/e+k7QEnt+7cNkoKN1cQfpwyB4EaFFE08xjV7p/gEFg u3esSlKa+BKskoounMHWQrQbFLS8UHp7ZE8B5aCuTg45In7rff2I26gO87SJKPCdxT YpdRng64+N/gA== Received: from jsievers.comcast.net ([12.187.116.132]) by resomta-po-20v.sys.comcast.net with SMTP id oH3vereohAxx6oH3yeFkqp; Tue, 20 Feb 2018 23:11:12 +0000 Received: from jsievers.enova.com (localhost [127.0.0.1]) by jsievers.comcast.net (Postfix) with ESMTP id 924F6260056; Tue, 20 Feb 2018 17:11:03 -0600 (CST) From: Jerry Sievers To: "Telium Technical Support" Cc: Subject: Re: PostgreSQL recovery file syntax, ver 8.4 vs ver 9.5 References: <000301d3aa8b$a70c17c0$f5244740$@telium.ca> <0f2b60dc-b095-d04c-c242-b79fdcacd32b@2ndquadrant.com> <002001d3aa95$d25940b0$770bc210$@telium.ca> Date: Tue, 20 Feb 2018 17:11:03 -0600 In-Reply-To: <002001d3aa95$d25940b0$770bc210$@telium.ca> (Telium Technical Support's message of "Tue, 20 Feb 2018 16:57:32 -0500") Message-ID: <871shf6yuw.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4wfMUMd9uGOY4FBHhUmMnTRR1FQsD3cWTgYxy+zCn1e7rETpOxenVUOI5s6oYd5s7mHj+WKzefLPZRWxG164ejr05oitKblgmO0yo15BZqLcPcMj52zB3G 6dRqD4coP7M9Q+TDrWHlJ4uBL2dng+a1ZiV8tF+WS/HzVzxQEnriMnUMRGakFBaigvciBctFrEQ0FMhwG8hpwEM9ceBDAF99GREeUg7eAzDYoblXXHlSw/kH List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk "Telium Technical Support" writes: > I actually need the log shipping so I can decide whether or not I want the > standby to accept data from the master (In case of master corruption). I > have clients on ver 8.4 and 9.5 so I'm trying to figure out if I can share > config settings between clients. Probably if your don't mind playing to the least version. FYI that later versions such as 9.5 support a lag time as recovery_min_apply_delay which might make unnecessary any external foo to hold back WAL files till some ageing time. > > -----Original Message----- > From: Peter Eisentraut [mailto:peter.eisentraut@2ndquadrant.com]=20 > Sent: Tuesday, February 20, 2018 4:44 PM > To: Telium Technical Support ; > pgsql-admin@lists.postgresql.org > Subject: Re: PostgreSQL recovery file syntax, ver 8.4 vs ver 9.5 > > On 2/20/18 15:44, Telium Technical Support wrote: >> In postgreSQL version 8.4 it seems that you can place the db server=20 >> into warm standby mode with the following setting in recovery.conf >>=20 >> =C2=A0 =C2=A0=C2=A0restore_command =3D 'pg_standby archiveDir %f %p %r' >>=20 >> In postgreSQL version 9.5 I see the same option, but I also see what=20 >> appears to be an alternative syntax in recovery.conf: >>=20 >> =C2=A0=C2=A0 standby_mode =3D (boolean) >> =C2=A0 =C2=A0trigger_file =3D (string) >>=20 >> So is this new syntax an alternative to the old syntax (both are=20 >> accepted by PGSQL)? Any benefit to the new syntax? >>=20 >> Does the new syntax mean that I can use the restore_command setting as=20 >> well (to use my own copy command)? > > A lot has changed between 8.4 and 9.5. Hot standby, streaming replicatio= n, > replication slots, and so on. You can continue to use pg_standby, but the > new facilities are better in many ways. --=20 Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@comcast.net p: 312.241.7800