Re: Assert in pageinspect with NULL pages

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Daria Lepikhova <d(dot)lepikhova(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Assert in pageinspect with NULL pages
Date: 2022-03-23 08:16:41
Message-ID: YjrXaecdozs6EzYe@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 18, 2022 at 06:43:39AM +0300, Alexander Lakhin wrote:
> Hello Michael,
> No, just x86_64, Ubuntu 20.04, gcc 11, valgrind 3.15. I just put that query
> in page.sql and see the server abort.

Bah, of course, I have missed the valgrind part of the problem.

The problem is that we attempt to verify a heap page here but its
pd_special is BLCKSZ. This causes BrinPageType() to grab back a
position of the area at the exact end of the page, via
PageGetSpecialPointer(), hence the failure in reading two bytes
outside the page. The result here is that the set of defenses in
verify_brin_page() is poor: we should at least make sure that the
special area is available for a read. As far as I can see, this is
also possible in bt_page_items_bytea(), gist_page_opaque_info(),
gin_metapage_info() and gin_page_opaque_info(). All those code paths
should be protected with some checks on PageGetSpecialSize(), I
guess, before attempting to read the special area of the page. Hash
indexes are protected by checking the expected size of the special
area, and one code path of btree relies on the opened relation to be a
btree index.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-03-23 08:27:50 Re: shared-memory based stats collector - v67
Previous Message Kyotaro Horiguchi 2022-03-23 07:38:33 Re: shared-memory based stats collector - v67