From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Yet another fast GiST build |
Date: | 2021-01-15 17:05:49 |
Message-ID: | 3B95DE5B-E376-45F7-BF7B-5BF53D99C7E8@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 15 янв. 2021 г., в 10:24, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> написал(а):
>
> I noticed this patch while working on another patch for pageinspect [0], and this one appears to introduce a problem similar to the one the other patch attempts to fix: The "itemlen" output parameters are declared to be of type smallint, but the underlying C data is of type uint16 (OffsetNumber). I don't know the details of gist enough to determine whether overflow is possible here. If not, perhaps a check or at least a comment would be useful. Otherwise, these parameters should be of type int in SQL.
Item offsets cannot exceed maximum block size of 32768. And even 32768/sizeof(ItemId). Thus overflow is impossible.
Interesting question is wether pageinspect should protect itself from corrupted input?
Generating description from bogus tuple, probably, can go wrong.
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-01-15 17:06:31 | Re: PG vs LLVM 12 on seawasp, next round |
Previous Message | Simon Riggs | 2021-01-15 17:01:57 | Re: WIP: System Versioned Temporal Table |