Re: Caveats from reloption toast_tuple_target

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Caveats from reloption toast_tuple_target
Date: 2019-05-21 04:18:03
Message-ID: 20190521041803.GC1921@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 21, 2019 at 12:33:54PM +1200, David Rowley wrote:
> 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.

Sure, this one would be possible as well. Much less likely I guess as
I don't imagine a lot of our user base which perform upgrades to new
instances by changing the page size. One way to trick that would be
to use a ratio of the page size instead. I would imagine that
changing compile-time constraints when moving to a new version
increases since we have logical replication so as you can move things
with close to zero downtime without relying on the physical page
size.

> 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.

Yes, I moved this item without seeing any replies. Anyway, it's
really the kind of thing I'd rather not touch post beta, and I
see disadvantages in doing what you and Pavan propose as well. There
is as well the argument that tuple_toast_target is so specialized that
close to zero people are using it, hence changing its lower bound
would impact nobody.

> 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.

Sure. Other opinions are welcome. Perhaps I lack insight and user
stories on the matter, but I unfortunately see downsides in all things
discussed. I am a rather pessimistic guy by nature.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul A Jungwirth 2019-05-21 04:25:39 Re: clean up docs for v12
Previous Message Amit Langote 2019-05-21 04:04:48 Re: clean up docs for v12