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 1k4BGj-0002zL-UT for pgsql-hackers@arkaria.postgresql.org; Fri, 07 Aug 2020 22:55:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k4BGi-0003Nj-Oh for pgsql-hackers@arkaria.postgresql.org; Fri, 07 Aug 2020 22:55:20 +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 1k4BGi-0003Nc-DA for pgsql-hackers@lists.postgresql.org; Fri, 07 Aug 2020 22:55:20 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k4BGf-0002mC-CP for pgsql-hackers@lists.postgresql.org; Fri, 07 Aug 2020 22:55:19 +0000 Received: by mail-qt1-x844.google.com with SMTP id x12so2546016qtp.1 for ; Fri, 07 Aug 2020 15:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ZM1UHzlPLzrSYLUaQbvO92RIho4FZKEFjU7n3UzdFoY=; b=FH9LjS02e4pQttSdlXJauuCTDXlB/dNUWbGhDEXh7lKHq2k86Sj4Xafig0C6uxC8UY SXT6gceToM8Let+xwOmLwfAe7uV/6l2ZtNPpoRhgwIE81wvrdyx6Kc9f+YU5Yax1kjAd KEizyvif0xbOEZFw+pQ97N84rMlWHfikBdqXOtNF+MaOgTB1+qMxT+2au30sDniB3KFz Nw/kX1b+gk5R/yq7MyeQJqAUpi9wqdBycK3Q1uoyPd5+SAanpNthuSiFjeVMP1F+MuGf QINQlzwmSRD8TL//kCCEHYcKx6faSdSEsCsp7WSS9Bv7u+pQAnXKk++MmU9BuI2LoQHs vUvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=ZM1UHzlPLzrSYLUaQbvO92RIho4FZKEFjU7n3UzdFoY=; b=eDye/ePFh+BRgp9VbLK5CKx9no7wtJpYeLrjqfnqTarJwvG69P3LS+NZtmrTp9BwCg cqsHPSr/nEya+xK82YbwUIm5OQypBZXsRbY6i2+54GKZBRKP5o+Xgw+8h0zuLU5jiNH9 cFL5J1N8sXgmXbitimMx/RrEsfIPTxsJi1YPysYdjrgyq1gEbqmezesO5q5cuz6du0LK iHGf6nAxu3tJaQw69K/mq429Kbb7CSHHDE76uDqDB8gJOvSTaFhvSvib1Qfl+x4qE4F9 N1JU6S9Mj6V3BWdmehp99LdGQuXgf/9TYSd5e5zDM7H0OO16KqbRCArKo2uy38YwdtRK WVdg== X-Gm-Message-State: AOAM531TlmS0dIBgj9U5/BF6OG0jLHegTw5t+4+G3CYHDCa09pl2vznA ipNHj770KPZ7SxXiDkX5IJjj8w== X-Google-Smtp-Source: ABdhPJw6Nnjd5u7j1NO30yVkMXSop6FL4idfNoIExzzceabtCPzWUuOmhdHSAQR5/ZZ+MQVbrOVxhQ== X-Received: by 2002:ac8:704:: with SMTP id g4mr16605486qth.250.1596840915558; Fri, 07 Aug 2020 15:55:15 -0700 (PDT) Received: from perhan.alvh.no-ip.org ([190.95.19.47]) by smtp.gmail.com with ESMTPSA id y3sm4129179qkd.132.2020.08.07.15.55.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2020 15:55:14 -0700 (PDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id F3DBA2A0FB2; Fri, 7 Aug 2020 18:55:12 -0400 (-04) Date: Fri, 7 Aug 2020 18:55:12 -0400 From: Alvaro Herrera To: Pg Hackers Cc: ashutosh.bapat@2ndquadrant.com, Noah Misch Subject: Re: walsender waiting_for_ping spuriously set Message-ID: <20200807225512.GA28635@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200806225558.GA22401@alvherre.pgsql> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I just noticed that part of this comment I'm modifying: > @@ -1444,17 +1444,13 @@ WalSndWaitForWal(XLogRecPtr loc) > * We only send regular messages to the client for full decoded > * transactions, but a synchronous replication and walsender shutdown > * possibly are waiting for a later location. So, before sleeping, we > - * send a ping containing the flush location. If the receiver is > - * otherwise idle, this keepalive will trigger a reply. Processing the > - * reply will update these MyWalSnd locations. > + * send a ping containing the flush location. A reply from standby is > + * not needed and would be wasteful. was added very recently, in f246ea3b2a5e ("In caught-up logical walsender, sleep only in WalSndWaitForWal()."). Added Noah to CC. I think the walreceiver will only send a reply if wal_receiver_status_interval is set to a nonzero value. I don't understand what reason could there possibly be for setting this parameter to zero, but it seems better to be explicit about it, as this code is confusing enough. I'm thinking in keeping the sentences that were added in that commit, maybe like so: > * We only send regular messages to the client for full decoded > * transactions, but a synchronous replication and walsender shutdown > * possibly are waiting for a later location. So, before sleeping, we > + * send a ping containing the flush location. A reply from standby is > + * not needed and would be wasteful most of the time, > + * but if the receiver is otherwise idle and walreceiver status messages > + * are enabled, this keepalive will trigger a reply. Processing the > + * reply will update these MyWalSnd locations. (Also, the comment would be updated all the way back to 9.5, even if f246ea3b2a5e itself was not.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services