Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rgNKM-005jyr-Lu for pgsql-hackers@arkaria.postgresql.org; Sat, 02 Mar 2024 11:14:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rgNKK-00GMym-MB for pgsql-hackers@arkaria.postgresql.org; Sat, 02 Mar 2024 11:14:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rgNKK-00GMye-Ct for pgsql-hackers@lists.postgresql.org; Sat, 02 Mar 2024 11:14:48 +0000 Received: from mail-oo1-xc31.google.com ([2607:f8b0:4864:20::c31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rgNKE-002Omr-5e for pgsql-hackers@postgresql.org; Sat, 02 Mar 2024 11:14:48 +0000 Received: by mail-oo1-xc31.google.com with SMTP id 006d021491bc7-5a0d96012d0so1553037eaf.3 for ; Sat, 02 Mar 2024 03:14:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709378080; x=1709982880; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=U/bSm6oQjbLvZJTEepDm2P8N7b/XcAxDGC4lIsy++fg=; b=KZjH1cuWDK10nKt6LiBJ2sJiCI54rr8guP7XN9FDRfl8rphN/9GUojJtHJL4lycbI5 QxpnrmBhghyMmtOWR1MkbCMHXgO3NS+lGKro7em4c+EggXnXBwpUSjWPaZgaZ9Ku3WSD Urvhs2JNefEER9YNkV0UohrnBta9clKHP1aDB33BeFCBea47VNQ4HHrpZx1PAja+KHpH 4vlmPDrh10db8pIO6/aDCJajn3H/Kz62fp/H73PyTBbVN+1boCv/qtLqe2zuAPo1Ly10 QyiLa0q4FcHOK7zGgU/3hv+8qDM5HXE9iqQdW+vFX1j2AkKy2NLhE8Xk9cXDIOurjFG9 DNnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709378080; x=1709982880; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=U/bSm6oQjbLvZJTEepDm2P8N7b/XcAxDGC4lIsy++fg=; b=V4laYj7oB2lkOFsB6i8f5izxAwcnW4qjqdVIQicOM57udpbcu/dILw/04kkT4em+I+ ZbNQLn4AOMIqtO9ytBpRfo+DuaI8xRK/gqtBxNEoNbolSOymw153ZSullZPk5yuuBXtG Epzs778rSjCyuslwYAZHwSQMfoVCIrK9m8DJZrnmvju7q+mcpRuceFsn8gsSxHy0LW3Q 7nOX0qbS+/5xKv9kzyff0c3ScGv8boTVItUknPHx2ysagl7KrLL6mjxR0DJL1uDzSgui oam2vUqrHUGVlabHD/oeyUoiKEJnvmtOEX4mQ/xZgeql1OKVdC6l5qJnrRzyBWzhoqOx 4avA== X-Forwarded-Encrypted: i=1; AJvYcCXkkIlbeum5tw74EuKQAu1zCe/AaUFzwEHFcaevGnKH7qpYfcGKAC2BhcFbmrGrRJrYaRMM7Rczai6KvIafFqqtPCS3td/mgNkyjwVO X-Gm-Message-State: AOJu0YyWrDCuuP3qArOJfLUqLqj21g+/p16qfsQ3JSsL2R0xAeVJ0FO6 +8FBEuBR90l6wc6SN/dD8BIFFOcpP3fVbtOV2fDLQMHj6RLwy4U1GgqTEiXjF3GFsO8Qe51xSaP NSuwk7sYr63RpFFtsawFyFzSkjvn64W+pVYVSNQ== X-Google-Smtp-Source: AGHT+IFy3u/ZH5Y9RgxSeNM8xPPIf+eH0ygFNevuejG/vq67FR6zpwn2AJriDRSDTnIcud0Dy7XcRc4mj54ZJaGof1s= X-Received: by 2002:a05:6871:64f:b0:21e:858f:ec9a with SMTP id x15-20020a056871064f00b0021e858fec9amr3732804oan.30.1709378079760; Sat, 02 Mar 2024 03:14:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Sat, 2 Mar 2024 16:44:28 +0530 Message-ID: Subject: Re: Regardign RecentFlushPtr in WalSndWaitForWal() To: Matthias van de Meent Cc: shveta malik , pgsql-hackers , Robert Haas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Mar 1, 2024 at 4:40=E2=80=AFPM Matthias van de Meent wrote: > > On Mon, 26 Feb 2024 at 12:46, shveta malik wrote= : > > > > Hi hackers, > > > > I would like to understand why we have code [1] that retrieves > > RecentFlushPtr in WalSndWaitForWal() outside of the loop. We utilize > > RecentFlushPtr later within the loop, but prior to that, we already > > have [2]. Wouldn't [2] alone be sufficient? > > > > Just to check the impact, I ran 'make check-world' after removing [1], > > and did not see any issue exposed by the test at-least. > > Yeah, that seems accurate. > > > Any thoughts? > [...] > > [2]: > > /* Update our idea of the currently flushed position. *= / > > else if (!RecoveryInProgress()) > > I can't find where this "else" of this "else if" clause came from, as > this piece of code hasn't changed in years. > Right, I think the quoted code has check "if (!RecoveryInProgress())". > But apart from that, your > observation seems accurate, yes. > I also find the observation correct and the code has been like that since commit 5a991ef8 [1]. So, let's wait to see if Robert or Andres remembers the reason, otherwise, we should probably nuke this code. [1] commit 5a991ef8692ed0d170b44958a81a6bd70e90585c Author: Robert Haas Date: Mon Mar 10 13:50:28 2014 -0400 Allow logical decoding via the walsender interface. --=20 With Regards, Amit Kapila.