Date: Tue, 26 Nov 2024 12:24:37 +0300
From: Dmitry Nikitin <pgsql-hackers@dima.nikitin.name>
Reply-To: Dmitry Nikitin <pgsql-hackers@dima.nikitin.name>
Message-ID: <172136986.20241126122437@dima.nikitin.name>
Disposition-Notification-To: pgsql-hackers@dima.nikitin.name
Return-Receipt-To: pgsql-hackers@dima.nikitin.name
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
CC: pgsql-hackers@postgresql.org
Subject: Re: [PATCH] Missing Assert in the code
In-Reply-To: <202411251951.hblpeyqnncy2@alvherre.pgsql>
References: <196971412.20241125103227@dima.nikitin.name> <202411251951.hblpeyqnncy2@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/172136986.20241126122437%40dima.nikitin.name>
Precedence: bulk

Hello Alvaro,

Monday, November 25, 2024, 10:51:31 PM, you wrote:

AH> Hmm, I think if we believe this to be really possible, we should have an
AH> 'if/elog' test (or maybe a full ereport with ERRCODE_DATA_CORRUPTED
AH> errcode) rather than an assertion.  I think the assertion adds nothing
AH> of value here, but maybe an 'if' test would.
I don't mind of 'if' however it's not clear for me what to follow on other (error) branch of that 'if'.

AH> Did you examine the other callers of PageGetMaxOffsetNumber()?  It's a
AH> large bunch.
Mostly it used in loops. So some code will be gracefully skipped and that's it.
However the case discussed is different because -1 index of an array will be accessed. Which is much
worse than a bare assertion at least.


--
Best regards,
 Dmitry                            mailto:pgsql-hackers@dima.nikitin.name