Re: Caveats from reloption toast_tuple_target

On Tue, 14 May 2019 at 18:49, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> Now, can we really increase the minimum value as you and Pavan
> propose? For now anything between 128 and TOAST_TUPLE_TARGET gets
> silently ignored, but if we increase the threshold as you propose we
> could prevent some dumps to be restored, and as storage parameters are
> defined as part of a WITH clause in CREATE TABLE, this could break
> restores for a lot of users. We could tell pg_dump to enforce any
> values between 128 and TOAST_TUPLE_THRESHOLD to be enforced to
> TOAST_TUPLE_THRESHOLD, still that's a lot of complication just to take
> care of one inconsistency.

If we had reloption validation functions then we could, but we don't,
so it seems we'd have no choice but reporting a hard ERROR.

I guess it's not impossible for pg_dump to fail on this even without
this change. If someone had increased the limit on an instance with
say 16k page to something over what TOAST_TUPLE_TARGET_MAIN would be
on a standard instance, then restoring onto the 8k page instance will
fail. Of course, that's less likely since it's a whole other factor
in the equation, and it's still not impossible, so maybe we need to
think about it harder.

> Hence, based on that those arguments, there is option #3 to do
> nothing. Perhaps the surrounding comments could make the current
> behavior less confusing though.

I see this item has been moved to the "Nothing to do" section of the
open items list. I'd really like to see a few other people comment
before we go and ignore this. We only get 1 opportunity to release a
fix like this per year and it would be good to get further
confirmation if we want to leave this.

In my view, someone who has to go to the trouble of changing this
setting is probably going to have quite a bit of data in their
database and is quite unlikely to be using pg_dump due to that. Does
that mean we can make this cause an ERROR?... I don't know, but would
be good to hear what others think.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services