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 1oplwD-0004iI-Pr for pgsql-admin@arkaria.postgresql.org; Tue, 01 Nov 2022 07:43:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oplwC-00087K-DW for pgsql-admin@arkaria.postgresql.org; Tue, 01 Nov 2022 07:43:56 +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 1oplwC-00087B-18 for pgsql-admin@lists.postgresql.org; Tue, 01 Nov 2022 07:43:56 +0000 Received: from mail-oa1-x30.google.com ([2001:4860:4864:20::30]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oplw5-00046W-1Y for pgsql-admin@lists.postgresql.org; Tue, 01 Nov 2022 07:43:54 +0000 Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-13ba9a4430cso15968744fac.11 for ; Tue, 01 Nov 2022 00:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=jz5K0CScxTIEYDS2ZTF2qVCOmCsjtP9bbJOx0Me4Lr8=; b=KnACfMKQZIFKSfRrJGsbEZCpy1NB+K+rxm7b9uZLEoAXM81BXURENKZNLS5SQqzyVj rEeJhn8bowgzwk8RBaYk6D6gTgug0pMW4ZflDD8P6COToAuLgLrT9kBeRRg5ejMI7Rav emOfDSDUZkaoYINZJtuWsobyD9fBqyoRyEYo33wz/ATT2Z3AhJDekqUrJh1nwEk8fN54 P61AC6TyLGn9nBoMm6wd/DMKQN/P99a7wQNcmgrD+PRiBS0D1WGggEYEWfUa7FQYfPBG BAu4eGOqtGmGv5l1vnYt7C2gHoQq3q37tEDRzJ0MurTiblQmKIiNXe5F21BlW2g/iUuc g4QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=jz5K0CScxTIEYDS2ZTF2qVCOmCsjtP9bbJOx0Me4Lr8=; b=SJzAlDE3kSraDRAr7bLrMfCy3aeMm9G7hJAZ7nD8xDSMca54DeU0EWy/Tg3tp2/yFS wH/hIyhEyEDUKFY5rCYOpfocX8Lss10Mqo/iPFpU8gbNhhXb96CgM1QQaMhRDWE+YL+D SE1xf3+eZ/xFWsoWYePD7ou2jdKnjyyktbK4M6E5SMnrxhofDAvehrT0wshgzfO8Oiac zo/f7cKeWJPc7Kfv4eKcyaT/6NGcX/p4QSgSuAvFbaEw9Je7TaqW3qexsfVfPfvDB9gZ r8SyXvJ+hegPfY26G5ipzG6qZH2CL50SFuToNR1b75Rv0RWxFzD5BgnvFDk+ts4Lln/K HJ6Q== X-Gm-Message-State: ACrzQf0GSCHmU8UXOJsZ6bib0AeE3emscm3NgxsIMWrcO60rjWtfR1ic C7s42zjjtIY+HE3C3uiyxsk8SliQJPo= X-Google-Smtp-Source: AMsMyM65vy0SMMBaCAYdXaafvM5hxjV8NwYJ/KDp7TPax3VNl2WvLrmdPe9li0YQsDaISSAdw+ODdQ== X-Received: by 2002:a05:6870:3120:b0:132:7d08:7059 with SMTP id v32-20020a056870312000b001327d087059mr10379854oaa.226.1667288628204; Tue, 01 Nov 2022 00:43:48 -0700 (PDT) Received: from [192.168.88.10] (ip68-11-68-85.no.no.cox.net. [68.11.68.85]) by smtp.googlemail.com with ESMTPSA id p3-20020a0568301d4300b006391adb6034sm3543818oth.72.2022.11.01.00.43.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Nov 2022 00:43:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------UcrwJboHCPRoQ00P2Kap20sM" Message-ID: <8f9e6c92-4daa-a543-6825-05a3503f4296@gmail.com> Date: Tue, 1 Nov 2022 02:43:46 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [External] Re: WAL Replication query Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: <88faef33e966796226022d6e7f3e32ad6c59fcfd.camel@cybertec.at> From: Ron In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------UcrwJboHCPRoQ00P2Kap20sM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/1/22 01:53, Laurenz Albe wrote: > On Tue, 2022-11-01 at 06:44 +0000, Sacheen Birhade wrote: >> If replication is in asynchronous then there will be data loss, right Laurenz? > Why? The data will perhaps show up on the standby a little later, but why is > that data loss? Remember that the question was about replication, and there > was no mention of failover. No, the question was about a crash during replication: OP (not Sacheen, unless that person is using two email addresses) explicitly asked "*When the primary crashes*  due an unforeseen reason (what happens)?" If the two database systems are really busy, and especially if the network connection isn't fast enough, *async* replication means there *might* be some transactions committed on Primary which were queued for transmission, but hadn't yet made it to the Secondary, right? -- Angular momentum makes the world go 'round. --------------UcrwJboHCPRoQ00P2Kap20sM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 11/1/22 01:53, Laurenz Albe wrote:
On Tue, 2022-11-01 at 06:44 +0000, Sacheen Birhade wrote:
If replication is in asynchronous then there will be data loss, right Laurenz?
Why?  The data will perhaps show up on the standby a little later, but why is
that data loss?  Remember that the question was about replication, and there
was no mention of failover.

No, the question was about a crash during replication: OP (not Sacheen, unless that person is using two email addresses) explicitly asked "When the primary crashes  due an unforeseen reason (what happens)?"

If the two database systems are really busy, and especially if the network connection isn't fast enough, async replication means there might be some transactions committed on Primary which were queued for transmission, but hadn't yet made it to the Secondary, right?

--
Angular momentum makes the world go 'round.
--------------UcrwJboHCPRoQ00P2Kap20sM--