From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Extending amcheck to check toast size and compression |
Date: | 2021-07-14 14:57:47 |
Message-ID: | 29751EFD-91D8-4F2F-8416-030AD067F260@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Jul 14, 2021, at 3:33 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
>> +/* The largest valid toast va_rawsize */
>> +#define VARLENA_SIZE_LIMIT 0x3FFFFFFF
>> +
>
> Hmm, a toasted datum cannot be larger than MaxAllocSize, because it's reconstituted in a palloc'd datum, right?
No datum size exceeds MaxAllocSize, and no datum expands when compressed (because for those that do expand under any particular compression algorithm, we opt to instead store the datum uncompressed), so no valid toast pointer should contain a va_rawsize field greater than MaxAllocSize. Any toast pointers that have larger va_rawsize fields are therefore corrupt.
VARLENA_SIZE_LIMIT is defined here equal to MaxAllocSize:
src/include/utils/memutils.h:#define MaxAllocSize ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
Earlier versions of the patch used MaxAllocSize rather than defining VARLENA_SIZE_LIMIT, but review comments suggested that was less clear.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-07-14 15:02:47 | Re: Incorrect usage of strtol, atoi for non-numeric junk inputs |
Previous Message | Tomas Vondra | 2021-07-14 14:57:24 | Re: row filtering for logical replication |