Feedback-ID: id4a34324:Fastmail
Date: Mon, 22 Jan 2024 12:12:18 -0800
From: Andres Freund <andres@anarazel.de>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Dilip Kumar <dilipbalaut@gmail.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	pgsql-hackers@lists.postgresql.org,
	Nathan Bossart <nathandbossart@gmail.com>,
	Masahiko Sawada <sawada.mshk@gmail.com>
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when
 possible
Message-ID: <20240122201218.bclrdkwpmuk26fl3@awork3.anarazel.de>
References: 
 <CALj2ACV123Ke6wn05QCnCgJhFpcarGCv7sKM1p39t+qpUNHUgQ@mail.gmail.com>
 <20231104004348.zhxzk2p266i3r2z2@awork3.anarazel.de>
 <CALj2ACUSydTHPcucftm4XdiJ4osH8zeNENyADd-zfDzEMf6akA@mail.gmail.com>
 <20231109205836.zjoawdrn4q77yemv@awork3.anarazel.de>
 <CALj2ACXo-_boM3h-PJuvfuvFzP1nv2wcZBoZN_YbRbQBGQYAUg@mail.gmail.com>
 <CALj2ACVfFMfqD5oLzZSQQZWfXiJqd-NdX0_317veP6FuB31QWA@mail.gmail.com>
 <3750ff9c2a5556808827e7fc5bcc0bd16e9facf4.camel@j-davis.com>
 <CALj2ACXy5eA-Y4Qgm3MUYZTGr_opNm2SzGtN+Zj6dbcSzqHrJA@mail.gmail.com>
 <73df9831747b01ced949102610dc44ca6026ee1c.camel@j-davis.com>
 <CALj2ACWPKuoUdA7r4VFKhsTZeNekyUr=ZwM6ckyvJ0qv2f6Whg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CALj2ACWPKuoUdA7r4VFKhsTZeNekyUr=ZwM6ckyvJ0qv2f6Whg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20240122201218.bclrdkwpmuk26fl3%40awork3.anarazel.de>
Precedence: bulk

Hi,

On 2024-01-10 19:59:29 +0530, Bharath Rupireddy wrote:
> +		/*
> +		 * Typically, we must not read a WAL buffer page that just got
> +		 * initialized. Because we waited enough for the in-progress WAL
> +		 * insertions to finish above. However, there can exist a slight
> +		 * window after the above wait finishes in which the read buffer page
> +		 * can get replaced especially under high WAL generation rates. After
> +		 * all, we are reading from WAL buffers without any locks here. So,
> +		 * let's not count such a page in.
> +		 */
> +		phdr = (XLogPageHeader) page;
> +		if (!(phdr->xlp_magic == XLOG_PAGE_MAGIC &&
> +			  phdr->xlp_pageaddr == (ptr - (ptr % XLOG_BLCKSZ)) &&
> +			  phdr->xlp_tli == tli))
> +			break;

I still think that anything that requires such checks shouldn't be
merged. It's completely bogus to check page contents for validity when we
should have metadata telling us which range of the buffers is valid and which
not.

Greetings,

Andres Freund