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 1rZhfu-005xeI-OH for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Feb 2024 01:33:31 +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 1rZhft-00Ehud-Gl for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Feb 2024 01:33:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rZhft-00EhuU-3P for pgsql-hackers@lists.postgresql.org; Tue, 13 Feb 2024 01:33:29 +0000 Received: from mail-oi1-x229.google.com ([2607:f8b0:4864:20::229]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rZhfq-006SWw-9n for pgsql-hackers@lists.postgresql.org; Tue, 13 Feb 2024 01:33:27 +0000 Received: by mail-oi1-x229.google.com with SMTP id 5614622812f47-3bb9d54575cso2917878b6e.2 for ; Mon, 12 Feb 2024 17:33:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20230601.gappssmtp.com; s=20230601; t=1707788006; x=1708392806; darn=lists.postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=/n1JVYk7UIw+RknhoNjQRcbvxrmNgttvm1qBM9dNGG0=; b=P/T/zYV+BjwfIBSWteDwnI8aBfUlDiKjz+KTVzqctUP2zt8fRSWZ7ohruALVjdnmlX SnLfe0RSu6HGzrdnx7A42eGkGrOwWzfXHL8vt3R4vIhSb2pcGyW8XiIFpz9Ygheqx2eg 9rZUovzz9lP6BmILefaXp/Sl6v6dc+AHBuIOAjt00GtzGs6wMrzsuaiwpsaO6QTsDDdz DkgU1VnSnW2LrTgcXsmFik2MStf4XB73dQfS4QmIqg54kT5ec8+nIJ6mAmE6ixgQNopo NVpzo2S8ZKMA+wokTWyu0zSlbMvsC7HmNWSrpPN1KhkGk1zyq5R9Dpmj29w8OvGT6LcF QRXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707788006; x=1708392806; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=/n1JVYk7UIw+RknhoNjQRcbvxrmNgttvm1qBM9dNGG0=; b=q472qY2XVDoPn9Ry5OSB3ycpjINcdabwjzeKZs9XOR+0LaEqksv4Bv63asZmomOGRR bF4iVQB4Q42bnoy0SylgLLfUov4sCsTyWZ9D5ARPDOLymnRbB+hr2QfpTaTu+8a87PAX 4sUZ8tuLMj93qrtA1xyfQ757e1+M4f1xWgQFqST1pnRWo2d8ep4RnWHVjacscb3ara0N zEoFqT8A0+tXcoDni6ZXEnXswcK7RQj3BbsDlGMOqVfTIpTSNY9RLD/ULY0blgPk4MEt tqMouMTrdJwfULI90MyVQWAY4BE0AJPMyz6ywc73cylP5IW7OnQYZwp472buqRnhjUyH roeg== X-Forwarded-Encrypted: i=1; AJvYcCUrd9HEir3c7ZhWpeI34dAYjdEcklywc9AUNDcCGuYJklaGo/lSsu+I3TuB7n9dTjNPNWlu0ktMijPpc95o/oPboj7aPGE4qyXMJyA8Hea9jpuZ X-Gm-Message-State: AOJu0Yw0mCdHDBOzgqiDrCW6ZfDrNLE2UGGiOOy1iB0WxJ+BoeM7ma4i eZefZhaICisQKy0gI9RGLgZ8rnFkVcxlAttLxyX4gwWQ+pS54ZrszT0Tddj+4Q== X-Google-Smtp-Source: AGHT+IGGAigkU7DG9Zg2rwRY1epDwjfbiP6vlsY7XjFttPhqFQ/6Aw36g8HiuHk53GKgb4LBMQ62Cg== X-Received: by 2002:a05:6870:1649:b0:219:a6d7:d01e with SMTP id c9-20020a056870164900b00219a6d7d01emr9446286oae.56.1707788005850; Mon, 12 Feb 2024 17:33:25 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVBWBYkxfEYm63IQ7VFMdL5oZhmuv0b0sa4RJX8oUWSL+lEv/25UwFd/kbkjDEyhiBhcxM5jLLpvi4nMn8etiN4Fmd2uM1vQSbNIq5SrfVqS0hablD0guXP2Wb7Iv79f2NqgTnQbD8lPHUnYW+5slb4mDlIkXLK3RFiY1jXybkMeNVz7H2fiQ9E6Ncs/+oBJX1BPw7jsfIN0eXIYQVaI1n8P48aKjJkzcDosZ7IgwTzuEawPyufRapTlSZmTTHQhvtVHCn91wATS6rK5AI= Received: from [172.18.10.46] ([12.126.244.130]) by smtp.gmail.com with ESMTPSA id t16-20020a63b250000000b005cfbf96c733sm1131931pgo.30.2024.02.12.17.33.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 17:33:25 -0800 (PST) Message-ID: Subject: Re: Improve WALRead() to suck data directly from WAL buffers when possible From: Jeff Davis To: Andres Freund Cc: Bharath Rupireddy , Alvaro Herrera , Dilip Kumar , Kyotaro Horiguchi , pgsql-hackers@lists.postgresql.org, Nathan Bossart , Masahiko Sawada Date: Mon, 12 Feb 2024 17:33:24 -0800 In-Reply-To: <20240212233648.4ephivkh7ukkiv2k@awork3.anarazel.de> References: <202401301731.o3cthlcry4ve@alvherre.pgsql> <20240212201853.r6dl25onohrwagxt@awork3.anarazel.de> <20240212233648.4ephivkh7ukkiv2k@awork3.anarazel.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 2024-02-12 at 15:36 -0800, Andres Freund wrote: >=20 > It doesn't really seem like a necessary, or even particularly useful, > part. You couldn't just call WALRead() for that, since the caller > would need > to know the range up to which WAL is valid but not yet flushed as > well. Thus > the caller would need to first use WaitXLogInsertionsToFinish() or > something > like it anyway - and then there's no point in doing the WALRead() > anymore. I follow until the last part. Did you mean "and then there's no point in doing the WaitXLogInsertionsToFinish() in WALReadFromBuffers() anymore"? For now, should I assert that the requested WAL data is before the Flush pointer or assert that it's before the Write pointer? > Note that for replicating unflushed data, we *still* might need to > fall back > to reading WAL data from disk. In which case not asserting in > WALRead() would > just make it hard to find bugs, because not using > WaitXLogInsertionsToFinish() > would appear to work as long as data is in wal buffers, but as soon > as we'd > fall back to on-disk (but unflushed) data, we'd send bogus WAL. That makes me wonder whether my previous idea[1] might matter: when some buffers have been evicted, should WALReadFromBuffers() keep going through the loop and return the end portion of the requested data rather than the beginning? We can sort that out when we get closer to replicating unflushed WAL. Regards, Jeff Davis [1]=20 https://www.postgresql.org/message-id/2b36bf99e762e65db0dafbf8d338756cf5fa6= ece.camel@j-davis.com