Date: Tue, 23 Jan 2024 13:13:56 +0900 (JST)
Message-Id: <20240123.131356.1249290340476643043.horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: aleksander@timescale.com, pgsql-hackers@lists.postgresql.org,
 vignesh21@gmail.com, stark.cfm@gmail.com, alvherre@alvh.no-ip.org,
 pryzby@telsasoft.com, andres@anarazel.de, ashu.coek88@gmail.com,
 pashkin.elfe@gmail.com, bossartn@amazon.com, david@pgmasters.net,
 peter.eisentraut@2ndquadrant.com, jtc331@gmail.com, robertmhaas@gmail.com
Subject: Re: Make mesage at end-of-recovery less scary.
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
In-Reply-To: <ZadmUE-edk2Z4CQU@paquier.xyz>
References: <20240116.115703.2298339297458587094.horikyota.ntt@gmail.com>
	<CAJ7c6TPnb2PUvV1xU8mUhos+A-8zB4r+KzTCxfyKvDS1if7BQA@mail.gmail.com>
	<ZadmUE-edk2Z4CQU@paquier.xyz>
User-Agent: Mew version 6.8 on Emacs 27.2
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
 boundary="--Next_Part(Tue_Jan_23_13_13_56_2024_752)--"
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20240123.131356.1249290340476643043.horikyota.ntt%40gmail.com>
Precedence: bulk

----Next_Part(Tue_Jan_23_13_13_56_2024_752)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

At Wed, 17 Jan 2024 14:32:00 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Tue, Jan 16, 2024 at 02:46:02PM +0300, Aleksander Alekseev wrote:
> >> For now, let me explain the basis for this patch. The fundamental
> >> issue is that these warnings that always appear are, in practice, not
> >> a problem in almost all cases. Some of those who encounter them for
> >> the first time may feel uneasy and reach out with inquiries. On the
> >> other hand, those familiar with these warnings tend to ignore them and
> >> only pay attention to details when actual issues arise. Therefore, the
> >> intention of this patch is to label them as "no issue" unless a
> >> problem is blatantly evident, in order to prevent unnecessary concern.
> > 
> > I agree and don't mind affecting the error message per se.
> > 
> > However I see that the actual logic of how WAL is processed is being
> > changed. If we do this, at very least it requires thorough thinking. I
> > strongly suspect that the proposed code is wrong and/or not safe
> > and/or less safe than it is now for the reasons named above.
> 
> FWIW, that pretty much sums up my feeling regarding this patch,
> because an error, basically any error, would hurt back very badly.
> Sure, the error messages we generate now when reaching the end of WAL
> can sound scary, and they are (I suspect that's not really the case
> for anybody who has history doing support with PostgreSQL because a
> bunch of these messages are old enough to vote, but I can understand
> that anybody would freak out the first time they see that).
> 
> However, per the recent issues we've had in this area, like
> cd7f19da3468 but I'm more thinking about 6b18b3fe2c2f and
> bae868caf222, I am of the opinion that the header validation, the
> empty page case in XLogReaderValidatePageHeader() and the record read
> changes are risky enough that I am not convinced that the gains are
> worth the risks taken.
> 
> The error stack in the WAL reader is complicated enough that making it
> more complicated as the patch proposes does not sound like not a good
> tradeoff to me to make the reports related to the end of WAL cleaner
> for the end-user.  I agree that we should do something, but the patch
> does not seem like a good step towards this goal.  Perhaps somebody
> would be more excited about this proposal than I am, of course.

Thank you both for the comments. The criticism seems valid. The
approach to identifying the end-of-WAL state in this patch is quite
heuristic, and its validity or safety can certainly be contested. On
the other hand, if we seek perfection in this area of judgment, we may
need to have the WAL format itself more robust. In any case, since the
majority of the feedback on this patch seems to be negative, I am
going to withdraw it if no supportive opinions emerge during this
commit-fest.

The attached patch addresses the errors reported by CF-bot.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

----Next_Part(Tue_Jan_23_13_13_56_2024_752)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="v29-0001-Make-End-Of-Recovery-error-less-scary.patch"