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