Re: pg_control is missing a field for LOBLKSIZE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_control is missing a field for LOBLKSIZE
Date: 2014-06-04 17:21:46
Message-ID: 31562.1401902506@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-06-04 17:33:16 Re: pg_control is missing a field for LOBLKSIZE
Previous Message Greg Stark 2014-06-04 17:17:29 Re: backup_label revisited