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 1p4bla-00023H-TS for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Dec 2022 05:54:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p4blZ-0004yj-DC for pgsql-hackers@arkaria.postgresql.org; Mon, 12 Dec 2022 05:54:17 +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 1p4blY-0004yQ-U9 for pgsql-hackers@lists.postgresql.org; Mon, 12 Dec 2022 05:54:16 +0000 Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1p4blW-00012v-LO for pgsql-hackers@postgresql.org; Mon, 12 Dec 2022 05:54:15 +0000 Received: by mail-pl1-x62e.google.com with SMTP id jn7so10964608plb.13 for ; Sun, 11 Dec 2022 21:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:from:to:cc:subject :date:message-id:reply-to; bh=Jhuxlp+pw9F3wCZD1Uzsmw4rH4UN/S3hgSvMpDoP+7U=; b=Kn+ihREVRnKNjyMwA8dZwRmJA+VMA4qg2oqemnlI3ehgQMQDA0LmbrgdxqJJqvf8f5 8tLUMSvkCDT+3ZdbhH0eQIBH2H6ryI7rq6HVhXVsqSfCE2CUZrMdcJ1hbs6RF7Dx3ho4 IWGYTqXLuNwuMHdzNJ7X/WqtqDpraNfiuDD06jidh1+SEvgH4XV8Tc4jSTJnY7FsQL6a S30s+Z3EkE5KX+GAIvHeApR1aHZmHP83BJJI5S9EfOKr0bm28Sujz+BQs8w0tM5yEluF JcYjciQo/qD8U8QJpf2eKPMpO7RxW9MyFlX+9DHIw0R+Cv5tIKUmY4FPJA4E3xdkTzdf OUpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Jhuxlp+pw9F3wCZD1Uzsmw4rH4UN/S3hgSvMpDoP+7U=; b=3KrVfYUblb8hu1OJO+Mi21n1DKM2xJhIKRXyVoIbvODyQLY0soKi581fiLLfijr+Dc 3INEMi5GDvNMgMngU1TBr0o6VnS6uSyBQgNtNhS6uiId0IJFirKR5LKDmZQRelMCKbgq OhIzz14kTHILx7QdS9aovZ58agXaptFyNZykWQm/f66XmLD0Vp8V/+s8qRvuhmbamR0s B/SssU86DXaW1F9Q4fkfiZkwdguU/P6naVvN7U5wu6TUavLpLI6qHuNVv2GwTbnG2ozw tShOVR1twh4Z30/xe4zreTsb5+DvQMB9KhlTfGPNJQfwRxiWl3WJmw9lp625MEPsrJOY 7Iew== X-Gm-Message-State: ANoB5pljnJoPuAiWYcYo2L2Kq2XQ378qwcyVXLze++bR9gpMaLkf9FDT gE3eSn5BPpOctIgm6hLKWEY= X-Google-Smtp-Source: AA0mqf6fAJrSOZUe8veKPTamGC9327QTt0doaV6BjrV0LtQemzxYBxKPxVoC8mchdao2M0do42Pw6A== X-Received: by 2002:a17:90b:1058:b0:219:9a95:ac1b with SMTP id gq24-20020a17090b105800b002199a95ac1bmr16978578pjb.21.1670824453224; Sun, 11 Dec 2022 21:54:13 -0800 (PST) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id d4-20020a17090ac24400b00205db4ff6dfsm4508987pjx.46.2022.12.11.21.54.10 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 11 Dec 2022 21:54:12 -0800 (PST) Date: Mon, 12 Dec 2022 14:54:09 +0900 (JST) Message-Id: <20221212.145409.1425479535653769807.horikyota.ntt@gmail.com> To: osumi.takamichi@fujitsu.com Cc: smithpb2250@gmail.com, euler@eulerto.com, m.melihmutlu@gmail.com, andres@anarazel.de, amit.kapila16@gmail.com, marcos@f10.com.br, pgsql-hackers@postgresql.org Subject: Re: Time delayed LR (WAS Re: logical replication restrictions) From: Kyotaro Horiguchi In-Reply-To: References: <07dfadac-493b-48c0-805e-83a3f735bed1@www.fastmail.com> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello. I asked about unexpected walsender termination caused by this feature but I think I didn't received an answer for it and the behavior is still exists. Specifically, if servers have the following settings, walsender terminates for replication timeout. After that, connection is restored after the LR delay elapses. Although it can be said to be working in that sense, the error happens repeatedly every about min_apply_delay internvals but is hard to distinguish from network troubles. I'm not sure you're deliberately okay with it but, I don't think the behavior causing replication timeouts is acceptable. > wal_sender_timeout = 10s; > wal_receiver_temeout = 10s; > > create subscription ... with (min_apply_delay='60s'); This is a kind of artificial but timeout=60s and delay=5m is not an uncommon setup and that also causes this "issue". subscriber: > 2022-12-12 14:17:18.139 JST LOG: terminating walsender process due to replication timeout > 2022-12-12 14:18:11.076 JST LOG: starting logical decoding for slot "s1" ... regards. -- Kyotaro Horiguchi NTT Open Source Software Center