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 1j3vKH-00056n-Ok for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Feb 2020 05:21:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j3vKF-0000Uk-1o for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Feb 2020 05:21:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j3vKE-0000Ud-FG for pgsql-hackers@lists.postgresql.org; Tue, 18 Feb 2020 05:21:38 +0000 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j3vKB-000519-SZ for pgsql-hackers@postgresql.org; Tue, 18 Feb 2020 05:21:36 +0000 Received: by mail-pl1-x62c.google.com with SMTP id t14so7599799plr.8 for ; Mon, 17 Feb 2020 21:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=ZmSNlZrIKjR+KJuAq/tGOsmLzHL4ko8joualdos5VKM=; b=HddjeieE0MRunVQiz9GDuq4vtU6n2dr4+1go6ZUDBxATIQNlnpV2awSsSzO93+NjuQ V5fEYgM7HFa/GFwRSCjfmT1E9Db+l9vsnjLdQVlaooQ6lP/ysT55DF9ZvKKjPAEZRwB6 Si4cOib4J+oCuctXjenRf+kSHma6rZ//f5MZzNt3d6es/rmEX6sOswnsVGclQm5TCCP5 ZeFlTA8CGxAV4ucN0sOfzkPcc3cZTBO/byttRbh0vfsk1O2PqFejmautf0LnL03Oj7ow PpdmxWAbJESEvJcdWChWwYos4mUowrj3kIMDctpaMh0vs3fFKop4hfVb4XaVgWFou7oS T5Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=ZmSNlZrIKjR+KJuAq/tGOsmLzHL4ko8joualdos5VKM=; b=cYvB9ZCLIWcXckQl6VWQWHTFRqdYg0SM5EEcwtih85aCUo2waqn8MIt38+RNNkrUmg 5z4+pXSk4OAoleH6qcxHXC7OB9TKGUqx/3kFOueit+e2vBUlRJIq/YtVJvgFv9islPVw 6r9rLC7a3JtSj12NCdum0CD/RGFr8ES9TLVWlR2IjxRane9gRBw98cfQGQDXpWRHkacm 4OXgPuQBTFVSN0yyjvM2bGmDmxhgs4MHilMdSNBzXrXnrMy4wDD4UZWZ+lVPL8doibOB y3py1a0f0ZARV/YuLhIoSnhcceeYRl+7+cFAJcf3ZmnFsWpEYQ/c4I6agoOZDsXeRWKd VX9w== X-Gm-Message-State: APjAAAX+Vl1C+lHuOVKNWG66uYrRyKXo7tm9puQrREBwQAeHsCO/ips7 ePOsJt432OnvV0B6BMTKB/E= X-Google-Smtp-Source: APXvYqzRVLeafAK2oIoP/85kRIFuaIKIlTWpmLmEbWwOkPBoSbxmknUg9ecFDJBBd4ToAMRjSIMSNg== X-Received: by 2002:a17:902:8a88:: with SMTP id p8mr18859513plo.179.1582003294632; Mon, 17 Feb 2020 21:21:34 -0800 (PST) Received: from localhost (w196209.dynamic.ppp.asahi-net.or.jp. [121.1.196.209]) by smtp.gmail.com with ESMTPSA id b3sm1193787pjo.30.2020.02.17.21.21.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Feb 2020 21:21:34 -0800 (PST) Date: Tue, 18 Feb 2020 14:20:16 +0900 (JST) Message-Id: <20200218.142016.2107516686265665330.horikyota.ntt@gmail.com> To: masao.fujii@oss.nttdata.com Cc: pgsql-hackers@postgresql.org Subject: Re: RecoveryWalAll and RecoveryWalStream wait events From: Kyotaro Horiguchi In-Reply-To: <124997ee-096a-5d09-d8da-2c7a57d0816e@oss.nttdata.com> References: <124997ee-096a-5d09-d8da-2c7a57d0816e@oss.nttdata.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: Precedence: bulk Hello. At Tue, 18 Feb 2020 12:25:51 +0900, Fujii Masao wrote in > Hi, > > RecoveryWalAll and RecoveryWalStream wait events are documented as > follows. > > RecoveryWalAll > Waiting for WAL from any kind of source (local, archive or stream) at > recovery. > > RecoveryWalStream > Waiting for WAL from a stream at recovery. > > But as far as I read the code, RecoveryWalAll is reported only when > waiting > for WAL from a stream. So the current description looks > incorrect. What's > described now for RecoveryWalStream seems rather fit to > RecoveryWalAll. > I'd like to change the description of RecoveryWalAll to "Waiting for > WAL > from a stream at recovery". Good catch! > Regarding RecoveryWalStream, as far as I read the code, while this > event is > being reported, the startup process is waiting for next trial to > retrieve > WAL data when WAL data is not available from any sources, based on > wal_retrieve_retry_interval. So this current description looks also > incorrect. I'd like to change it to "Waiting when WAL data is not > available > from any kind of sources (local, archive or stream) before trying > again > to retrieve WAL data". > > Thought? I agree that the corrected description sound correct in meaning. The latter seems a bit lengthy, though. > Also the current names of these wait events sound confusing. I think > that RecoveryWalAll should be changed to RecoveryWalStream. > RecoveryWalStream should be RecoveryRetrieveRetryInterval or > something. I agree to the former, I think RecoveryWalInterval works well enough. > Another problem is that the current wait event types of them also look > strange. Currently the type of them is Activity, but IMO it's better > to > use IPC for RecoveryWalAll because it's waiting for walreceiver to > receive new WAL. Also it's better to use Timeout for RecoveryWalStream > because it's waiting depending on wal_retrieve_retry_interval. Do you mean condition variable by the "IPC"? But the WaitLatch waits not only for new WAL but also for trigger, SIGHUP, shutdown and walreceiver events other than new WAL. I'm not sure that condition variable fits for the purpose. > The changes of wait event types and names would break the > compatibility > of wait events in pg_stat_activity. So this change should not be > applied > to the back branches, but it's ok to apply in the master. Right? FWIW, It seems right. regards. -- Kyotaro Horiguchi NTT Open Source Software Center