Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hnQK8-0003BC-BF for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Jul 2019 16:29:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hnQK7-0005ae-4Y for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Jul 2019 16:29:03 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1hnQK6-0005Tu-LE for pgsql-hackers@lists.postgresql.org; Tue, 16 Jul 2019 16:29:02 +0000 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hnQK4-0004mK-Gx for pgsql-hackers@postgresql.org; Tue, 16 Jul 2019 16:29:02 +0000 Received: by mail-wr1-x42a.google.com with SMTP id r1so21637321wrl.7 for ; Tue, 16 Jul 2019 09:29:00 -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=yWulCX7RnBQqh5ulPfOKGZ0NuJIzBf0S3PMi09IQwGo=; b=p82OHu+PC5GngPrW+wcwL62dXy4QmfbxRNMFsGKfN05X7RQSFVCMkWBw0lnwBLytBB 0p96ZyFAqNneEizuKOzUnMjkXBw/lvLLGtyyIbegpHbT5oQacDqELSyxx86Ev58JQMQT dKbhrpbyYI+ED4WEQu2LMqaDy6d/zPaRsVwnZ3UL9nNt5TAcGKjd+iNLDvcKXOL/RCaA g6JPwB2v8Vsdi/vp7uFwWqbs8mi10biOfhYLI9KdoZs4Y8k5zmq/WLFVZrvF5Dw3qUJD FRgGqEUyPU2yRxuA8Mjs6JR1kYcwkBfjaw6gUP3FrygFZ/JwATQWsnPLVZ6Iy7S/P+dw 9JIw== 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=yWulCX7RnBQqh5ulPfOKGZ0NuJIzBf0S3PMi09IQwGo=; b=otlEIC/pArp0XhSr5FSpyuwhSZq5NuVCYxJY+GJl4dwaVKGY5EyBOekyiDyIjkG62K 4Ri1OOPyMtHT0aqd9gmJiHobLyLhHLctQA4Ma5zByNgmw5MsEr6Z3CWOVEKTZcKi8SAv dZUyYwppWrLvJO2W0qX7sdjbOs8LfBVdv3umX27RoyKFWrntEfG3sJz3FLuUKRD3hNaK T2EWFOfp8aKnyoJOGWDBHrfaKttNPp78orJ6ZkI8rZk9EZeqd02I2Cd8rQ+dlBlLk3P6 2qiZ2sPu8DFIuK9Fy5MSybp3hqqYEDrCSrbfgIt61H0fRqL2p3maDS/mzNUpHpVrnWiH jYPQ== X-Gm-Message-State: APjAAAVuUfosO1Zou3DW0nxUROiNpNHMsAMajqF/yRVMgc8ney/13T3C aS9Bv042Tj3rBpriZ0D30N8= X-Google-Smtp-Source: APXvYqzeb3vxVTrUR5cwqD73KvFHnIIjmiPq+Yj3zqf/VwheGQd5yerUJg/kK2yzkTyWgepUraGcIA== X-Received: by 2002:a5d:5388:: with SMTP id d8mr36816760wrv.299.1563294538281; Tue, 16 Jul 2019 09:28:58 -0700 (PDT) Received: from localhost.localdomain (i59F7FF93.versanet.de. [89.247.255.147]) by smtp.gmail.com with ESMTPSA id e3sm18500672wrs.37.2019.07.16.09.28.57 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 16 Jul 2019 09:28:57 -0700 (PDT) Message-ID: Subject: Re: pg_receivewal documentation From: Laurenz Albe To: Michael Paquier , Jesper Pedersen Cc: Alvaro Herrera , PostgreSQL-development Date: Tue, 16 Jul 2019 18:28:57 +0200 In-Reply-To: <20190716050555.GA1439@paquier.xyz> References: <20190710142421.GA28387@alvherre.pgsql> <54779de5-f922-c0cf-629d-b582eded7265@redhat.com> <20190716050555.GA1439@paquier.xyz> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, 2019-07-16 at 14:05 +0900, Michael Paquier wrote: > >> How about > >> Note that while WAL will be flushed with this setting, > >> pg_receivewal never applies it, so > >> must not be set to > >> remote_apply if pg_receivewal > >> is the only synchronous standby. > > This is not true in all cases as since 9.6 it is possible to specify > multiple synchronous standbys. So if for example pg_receivewal and > another synchronous standby are set in s_s_names and that the number > of a FIRST (priority-based) or ANY (quorum set) is two, then the same > issue exists, but this documentation is incorrect. I think that we > should have a more extensive wording here, like "if pg_receivewal is > part of a quorum-based or priority-based set of synchronous standbys." I think this would be overly complicated. The wording above seems to cover the priority-based base sufficiently in my opinion. Maybe a second sentence with more detail would be better: ... must not be set to remote_apply if pg_receivewal is the only synchronous standby. Similarly, if pg_receivewal is part of a quorum-based set of synchronous standbys, it won't count towards the quorum if is set to remote_apply. Yours, Laurenz Albe