Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1civ4u-0000ij-Gg for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Mar 2017 03:37:24 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1civ4u-0006n1-0e for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Mar 2017 03:37:24 +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 1civ4s-0006ja-9e for pgsql-hackers@postgresql.org; Wed, 01 Mar 2017 03:37:22 +0000 Received: from mail.thelabyrinth.net ([45.56.70.56]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1civ4p-0002Qc-Ce for pgsql-hackers@postgresql.org; Wed, 01 Mar 2017 03:37:21 +0000 Received: from Davids-iMac.local (c-73-55-5-246.hsd1.fl.comcast.net [73.55.5.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dsteele) by mail.thelabyrinth.net (Postfix) with ESMTPSA id 7853A55666; Wed, 1 Mar 2017 03:37:15 +0000 (UTC) Subject: Re: PATCH: Make pg_stop_backup() archive wait optional To: Robert Haas References: <758e3fd1-45b4-5e28-75cd-e9e7f93a4c02@pgmasters.net> <35b7530c-68ce-7090-e13c-e39e4dac9bca@pgmasters.net> <967b90bd-6b65-a18a-5266-bfa9191c40e6@pgmasters.net> Cc: Michael Paquier , Pg Hackers From: David Steele Message-ID: Date: Tue, 28 Feb 2017 22:37:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 2/28/17 10:22 PM, Robert Haas wrote: > On Tue, Feb 28, 2017 at 6:22 AM, David Steele wrote: >>>> I'm not sure that's the case. It seems like it should lock just as >>>> multiple backends would now. One process would succeed and the others >>>> would error. Maybe I'm missing something? >>> >>> Hm, any errors happening in the workers would be reported to the >>> leader, meaning that even if one worker succeeded to run >>> pg_start_backup() it would be reported as an error at the end to the >>> client, no? By marking the exclusive function restricted we get sure >>> that it is just the leader that fails or succeeds. >> >> Good point, and it strengthens the argument beyond, "it just seems right." > > I think the argument should be based on whether or not the function > depends on backend-private state that will not be synchronized. > That's the definition of what makes something parallel-restricted or > not. Absolutely. Yesterday was a long day so I may have (perhaps) become a bit flippant. > It looks like pg_start_backup() and pg_stop_backup() depend on the > backend-private global variable nonexclusive_backup_running, so they > should be parallel-restricted. Agreed. -- -David david@pgmasters.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers