On Wed, Jun 4, 2014 at 1:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>>> I've not heard one either, but there was just somebody asking in
>>> pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
>>> That's not a big enough sample size to make me panic about getting a
>>> hasty fix into 9.4, but I do think we should fix this going forward.
>
>> Agreed.
>
> BTW, just comparing the handling of TOAST_MAX_CHUNK_SIZE and LOBLKSIZE,
> I noticed that the tuptoaster.c functions are reasonably paranoid about
> checking that toast chunks are the expected size, but the large object
> functions are not: the latter have either no check at all, or just an
> Assert that the size is not more than expected. So we could provide at
> least a partial guard against a wrong LOBLKSIZE configuration by making
> all the large-object functions throw elog(ERROR) if the length of a LO
> chunk is more than LOBLKSIZE. Unfortunately, length *less* than LOBLKSIZE
> is an expected case, so this would only help in one direction. Still,
> it'd be an easy and back-patchable change that would provide at least some
> defense, so I'm thinking of doing it.
This seems like a pretty weak argument for adding run-time overhead.
Maybe it can be justified on the grounds that it would catch corrupted
TOAST data, but I've never heard of anyone changing LOBLKSIZE and see
no reason to get agitated about it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
