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 1enwgI-0004yV-U5 for pgsql-docs@arkaria.postgresql.org; Tue, 20 Feb 2018 01:25:19 +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 1enwgG-0005Rl-97 for pgsql-docs@arkaria.postgresql.org; Tue, 20 Feb 2018 01:25:16 +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 1enwgF-0005RR-L9 for pgsql-docs@lists.postgresql.org; Tue, 20 Feb 2018 01:25:16 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1enwgC-0006aE-FD for pgsql-docs@lists.postgresql.org; Tue, 20 Feb 2018 01:25:14 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id EDDFEC6A; Mon, 19 Feb 2018 20:25:09 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 19 Feb 2018 20:25:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=TXXhyCGFC8H0pjeLon0oAdSCX2D/yManlmQXg7/waLY=; b=xeeVwOLF mpcBwi9cDdDKtHt7ddctrzmbR3YuquBXlveEbyoM9trSe3Ug2jT+/W4C53h+n+Uq Vrh0p5uuLKNi0Yv9FLP7MYvpBaihiPYPB5Z+1PCEGva/Uu6atouuUF0bWGm9nHZl 0tBs+H6DoTH8c7x5M43T0kNVyXArG+VKFreXJypVnPPafBwr0w2EPi/hdYEd4saM JIQmU6+ZxAWgz1W7BdjKvBzQYHAjvdE4GFSHoqTkqUZOkd3d/3A9eMQGR4oM/ZBC kYTPa5l1rqOwkh6ixzXAGBUu0yX5Ie/p54aLjTC5J3W3NN/U/QWKGhZdiUPueQjh PpUleeAt/k6Wkw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=TXXhyCGFC8H0pjeLon0oAdSCX2D/y ManlmQXg7/waLY=; b=RjYT7BEp+p5YA6Q/JD0DJCbG7cQ8MYl6Odsdk6VFp9jxk GsU1ESr1NaBUB5aq3C0scaJsV3p4vjnj3XWzIEO9zILu/fnziuZpeIgSFtqmjikC rjHUNn+aGWGrfaqnLB3oHI94w7v5mdefHsVPlQWwWSBh8iiAuuR05dBkR/7e6lY+ Ow3x6t1oClK8IBF8l1ynfQd69rTSie34q75IHjOsRsCInPUDLz+sUrnzOdp220gI i6fyfP0nBMLg7U2YOw4yATZS6OltN9mZ6bMYTwVNYw6/QD28jgYFav/uMh9Zns6Y SxT6ZrAkIPClsyseIceqCn8UzQtx8JGo/bjOCsvyA== X-ME-Sender: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id AEEA57E13F; Mon, 19 Feb 2018 20:25:08 -0500 (EST) Date: Tue, 20 Feb 2018 10:25:05 +0900 From: Michael Paquier To: markus.zwettler@zuerich.ch, pgsql-docs@lists.postgresql.org Subject: Re: docu bug? Message-ID: <20180220012505.GD26999@paquier.xyz> References: <151904846438.1392.12159208594449682757@wrigleys.postgresql.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IDYEmSnFhs3mNXr+" Content-Disposition: inline In-Reply-To: <151904846438.1392.12159208594449682757@wrigleys.postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --IDYEmSnFhs3mNXr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 19, 2018 at 01:54:24PM +0000, PG Doc comments form wrote: > The sample works with a NON-persistent connection (psql -c): >=20 > > 25.3.6.1. Standalone Hot Backups > ... touch /var/lib/pgsql/backup_in_progress > psql -c "select pg_start_backup('hot_backup');" > tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/ > psql -c "select pg_stop_backup();" > rm /var/lib/pgsql/backup_in_progress > tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/ > ... > This uses the set of exclusive backup APIs, so with non-persistent connections the backup can be correctly completed. Non-exclusive backups can be defined using 'false' as third argument of=20 pg_start_backup() and first argument of pg_stop_backup(). Note that for pg_start_backup you would also need to define the second boolean argument to decide if a checkpoint should be immediately taken or not. So you would have basically the following flow on a persistem connection: =3D# SELECT pg_start_backup('my_backup', true_or_false, false); -- keep connection alive and do stuff. =3D# SELECT pg_stop_backup(false); Do you think that the section "Tips and Examples" should mention that an exclusive backup method is used for this example? This may reduce the confusion. -- Michael --IDYEmSnFhs3mNXr+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlqLePEACgkQnvQgOdby QH1U0RAAggfefL7J26XbJCfU5zU3sKhuLIG8l4vZNX7avramhOoMR9u/SzJzC40B mbj5Nh5PK1oiFWGAC0BVRNqDJK2+8iUT+tZ04+OrrE7gp36JiIg4f0lhZM4v1PEb Ci1EYVrBu9xahcf+EcIP1CDmBxmaD4E6sJcfrw2CGFlYu/x+uPk40W50T2QN90Hz hJh96tojLfj89KWI3zlIoeyex31oN0rKDXacYcOBHNmJyTETdJ3UJmWWBgpZgvcs KInfm0LTj4/ys0d2nnaYmLIz8R9lJzJb9VHbr6SM6JjFOa/YdlMnF5no0I5TjtbA 22N1hRCLEZ6Ipn1daqY1yrSGo48MWcc9VMhBrKbNjuQQFL7GRQcgLJJQ7u1BK+E6 7RS0X2mjprZHc3wxI05M4ZMjhImaFM+uh91+czKaue+mWOLuQem5grn6YXANwc55 s47o9pKtvgGd9nVsQTFjyySTE1kem1wnEUy0jOGwMezJOFNRuAssM6YyAzpLYqA4 WzAVsfKaSdvrP6B8fLZu0ErfhtmyCOEJcy981VyoAtAEbIuhOO2B7n86Bzb1Qx1Z sftasfj0+iKCcXa6IT980Wxu7/2vyzDmEdM8gfTHQ7Gu4vgMmx5jpjemDBUPYOkA 9pIU1FnjJUBk8T31WF0CS0qlsWgoa73PxTi8KuXUnsFpF2Fm7yw= =QcTh -----END PGP SIGNATURE----- --IDYEmSnFhs3mNXr+--