Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kMosB-0001Yw-Qm for pgsql-docs@arkaria.postgresql.org; Mon, 28 Sep 2020 08:51:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kMosA-0002KK-Pq for pgsql-docs@arkaria.postgresql.org; Mon, 28 Sep 2020 08:51:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kMosA-0002KC-Fb for pgsql-docs@lists.postgresql.org; Mon, 28 Sep 2020 08:51:02 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kMos8-0000TX-3B for pgsql-docs@lists.postgresql.org; Mon, 28 Sep 2020 08:51:01 +0000 Received: by mail-wm1-x344.google.com with SMTP id s13so210287wmh.4 for ; Mon, 28 Sep 2020 01:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=EJ3MkW1tuSbjMjaJHDabq1Apqh8lVA4yuyNCjPCru38=; b=nebSCh40bFDp2wQDCCQadDwOKsIGzWpJXmP3LlPSY312focb2RSl1a6cIf5OlD1/U1 andzZnnRd0SAmR6QN1zTHQNvHXOwrpNQUjssufWhHaRQhdV2ZhJRIDMnJYmsL3etLjCb WlD+wz32h37qXojDYpNrVyTbz8dNPe1KBs9N1ps8FjFTh9+B5mfImzx5JDQu3jqUlpi/ b2uDRdMuxIGQnMk9RKTv6S0eKs3gYRLuemAYdP/h6O/UvlIopn4F3DjJ4nYIHgpedf+Z 19A3vIGx4PCa6zFWLsHjDLKUprVcgpDNsD+GCyrnbqXdG3w9SbrM5bGmTFfFwcRtogzF +p/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=EJ3MkW1tuSbjMjaJHDabq1Apqh8lVA4yuyNCjPCru38=; b=sQjCOSNhlaqAAJAnurAAui+4jw1KwkRAsQPwVAnj4qg/A/ASEoUg4EcWMVKSqJnFUG IIY5tBdo4pLAnnKyaTiz3AfxVEWrxv9PZyDPjMMdFuamoRfQhE5oBoXRJLiLSKk0ybY8 FMSv7oHd2p3VmYEVPUNALujdhmLTgYWarzBSbI3jW8SBkHYDEfxO1qLV4cmPmBu7CyZF k0xnd9blTbyCzQ5Hvz07npHja1AYg3i/3sHFHIrVjxbwRHTxHKRnbABv78IQrPvfpxPm faxz9Eewo82RCbF0/emskdwZpnFs2CU+5GFR/Mob/A9nQBtQr4gVzyx001rn7Y56owAx lfxg== X-Gm-Message-State: AOAM533Lpmem/4GvSDDooBSAZ7LaXbAKaVAL+ueiHlo7dJwvdRbFnsZN 1YcEvEKZnsiJA+1dm7wd5qZVdw== X-Google-Smtp-Source: ABdhPJy/AjOBPhDLdFWAi6ovW91TJqIviOzfIj6XmmWf/G6aJoS4GjZ9p/GZHQ9PT7IeqHjZMst1PQ== X-Received: by 2002:a1c:f619:: with SMTP id w25mr515532wmc.62.1601283058058; Mon, 28 Sep 2020 01:50:58 -0700 (PDT) Received: from localhost.localdomain ([212.186.219.234]) by smtp.gmail.com with ESMTPSA id s12sm322847wmd.20.2020.09.28.01.50.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Sep 2020 01:50:57 -0700 (PDT) Message-ID: <65ee31c337b0b832a21524f13e14ea8b2e475ac1.camel@cybertec.at> Subject: Re: Possible mistake in backup documentation From: Laurenz Albe To: Magnus Hagander Cc: abo@velvica.com, Pg Docs Date: Mon, 28 Sep 2020 10:50:57 +0200 In-Reply-To: References: <160078426053.14061.808669930112439771@wrigleys.postgresql.org> <3e33df71449fdc083b1ed8a4dfe3ee129de59798.camel@cybertec.at> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, 2020-09-25 at 14:50 +0200, Magnus Hagander wrote: > On Fri, Sep 25, 2020 at 2:32 PM Laurenz Albe wrote: > > On Tue, 2020-09-22 at 14:17 +0000, PG Doc comments form wrote: > > > In "25.3.3.2. Making An Exclusive Low-Level Backup", you said that "The > > > exclusive backup method is deprecated and should be avoided. Prior to > > > PostgreSQL 9.6, this was the only low-level method available, but it is now > > > recommended that all users upgrade their scripts to use non-exclusive > > > backups". But in the example in "25.3.6.1. Standalone Hot Backups" you use > > > the exclusive version of backup command. Is it a mistake or not? > > > > Yes, that's true. > > Well, technically it is *correct*. It's just rather silly that we are using the deprecated API in the example. > > > How about the attached patch? > > Perhaps that is too complicated, but I have no idea how to make it simpler. > > For this example, can't we just show two sessions. That is, "in a psql, run pg_start_backup(). > Then in a different session, copy all the files, and then back in psql run pg_stop_backup()" or such? > > This is still just an example of a low level operation, where the recommendation is (and is there iirc) > to use a different tool for it already. I thought the point of the example is to show a workable script that could perform a backup and could be used as a starting point to develop your own backup solution. (I know that there are people who think writing your own backup solution is evil, but I am not one of them.) If we replace that with a verbal description of how to do it, the example just duplicates what is already documented. In that case I would opt for simply removing the example. Yours, Laurenz Albe