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 1kfQCh-0007TH-Gk for pgsql-performance@arkaria.postgresql.org; Wed, 18 Nov 2020 16:21:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kfQCg-0004cz-Fj for pgsql-performance@arkaria.postgresql.org; Wed, 18 Nov 2020 16:21:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kfQCg-0004ak-4T for pgsql-performance@lists.postgresql.org; Wed, 18 Nov 2020 16:21:06 +0000 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kfQCb-0007aN-Hd for pgsql-performance@postgresql.org; Wed, 18 Nov 2020 16:21:05 +0000 Received: by mail-wm1-x32c.google.com with SMTP id h21so3255271wmb.2 for ; Wed, 18 Nov 2020 08:21:01 -0800 (PST) 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=HuCXs0EGO3Sb2ytmU8KITZ47y3kzyiyKCe7rFgUfPpM=; b=WwI5iQQQGR+XyIpjSI7WiOxzIhLG3B920hgEo7KUeWOWaWMmuhqqwWXMfHtJtBMJhD sKiPCUYxTAJXQcZ6ZeYwyG2om0vEeo6zuJx8ph+b7ZKDaftrUkICpJbvw4AkZcfpLyQv VkxILaG3nSzSd/XIvVaS++T7MTDqVFSxyQyI3ZtHXIgll9/5NwdJp3Ydng3tJ0Uo56oz E7rJg6g0xqcBjP10Dy/j3qPGYehEtZbePp7tGwZjWoTdYkm7t/VU/hpcIOEaYOg/UGuU VvwR4p5AIVrDYQ6w2s6oxKqoXWNtL8L36psN1bCgrsOaaI5GRLBUd8tNJDJZ/qr6q1OI gZ7A== 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=HuCXs0EGO3Sb2ytmU8KITZ47y3kzyiyKCe7rFgUfPpM=; b=p65pigXW2JedQu2pGpHbyQUu3O9AeRKswidy0GvndtqeO19lMoW8vR83i/C3MbMG1d bT5vjEvLvUpPIn13CxEDIPpep/RCLwMof676z+A5ODj5ma9+AEpeQqge6tlKBRqqpRuT nVZfC9LEcEk3eKc/EqB0dJXThfS1AIAMEqMuKwW4c/X/I5Y/ryv/EyNo3Y6o7Gwih3Gn FFCRCxZAqZzo64ix8uPs+pwv3hm6V9Cps/FeaVps3wRZ+kGgwQY3puK+QA5Ez7RvTPVE MxlRUFh01qZPQ6I4FlYrLc6JWeZqWAdgh4EMsniU9M36csbsqXBxUEx5m72lcBwNrH5d /vkg== X-Gm-Message-State: AOAM532kIVKZRk9IFgZzI3folJDZ+IntTnphE0rLReUslq0gmwhG8H8d JfE+LCafZ/tLYymBXzRAa4PyWw== X-Google-Smtp-Source: ABdhPJxT+rq9WCw0N1UQPuO6RgwtF/AlRZBZ/YVmr3l8rS8zMgik4x3lWdx6YVjsXHFEh/Zo8xRBaQ== X-Received: by 2002:a1c:f406:: with SMTP id z6mr806824wma.123.1605716460097; Wed, 18 Nov 2020 08:21:00 -0800 (PST) Received: from localhost.localdomain (217-149-169-56.nat.highway.telekom.at. [217.149.169.56]) by smtp.gmail.com with ESMTPSA id n9sm4597278wmd.4.2020.11.18.08.20.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Nov 2020 08:20:59 -0800 (PST) Message-ID: <6a3a9ef99167a7baeaeee3d3df4af59694277e36.camel@cybertec.at> Subject: Re: How to prioritise walsender reading from pg_wal over WAL writes? From: Laurenz Albe To: Alexey Bashtanov Cc: pgsql-performance@postgresql.org Date: Wed, 18 Nov 2020 17:20:58 +0100 In-Reply-To: References: <774ec1b8-c7c6-cfa2-098d-5c6a32dcfc1a@imap.cc> 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 Wed, 2020-11-18 at 12:15 +0000, Alexey Bashtanov wrote: > My reply did not get threaded appropriately. > My original question was here: > https://www.postgresql.org/message-id/a74d5732-60fd-d18b-05fd-7b2b97099f19%40imap.cc > I'd like to prioritize walsender for replication not to lag too much. > Otherwise, when I have load spikes on master, standby lags, sometimes by > hundreds of gigabytes. I would first determine where the bottleneck is. Is it really the walsender, or is it on the network or in the standby server's replay? Check the difference between "sent_lsn", "replay_lsn" from "pg_stat_replication" and pg_current_wal_lsn() on the primary. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com