Re: new heapcheck contrib module

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: new heapcheck contrib module
Дата
Msg-id A228DA6F-4671-4A2C-86B1-DB3E52BDADEB@enterprisedb.com
обсуждение исходный текст
Ответ на Re: new heapcheck contrib module  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: new heapcheck contrib module  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: new heapcheck contrib module  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

> On Oct 23, 2020, at 11:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Hmm, we're not out of the woods yet: thorntail is even less happy
> than before.
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=thorntail&dt=2020-10-23%2018%3A08%3A11
>
> I do not have 64-bit big-endian hardware to play with unfortunately.
> But what I suspect is happening here is less about endianness and
> more about alignment pickiness; or maybe we were unlucky enough to
> index off the end of the shmem segment.  I see that verify_heapam
> does this for non-redirect tuples:
>
>            /* Set up context information about this next tuple */
>            ctx.lp_len = ItemIdGetLength(ctx.itemid);
>            ctx.tuphdr = (HeapTupleHeader) PageGetItem(ctx.page, ctx.itemid);
>            ctx.natts = HeapTupleHeaderGetNatts(ctx.tuphdr);
>
> with absolutely no thought for the possibility that lp_off is out of
> range or not maxaligned.  The checks for a sane lp_len seem to have
> gone missing as well.

You certainly appear to be right about that.  I've added the extra checks, and extended the regression test to include
them. Patch attached. 



—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company




Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [doc] remove reference to pg_dump pre-8.1 switch behaviour
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Mop-up around psql's \connect behavior