Re: Caveats from reloption toast_tuple_target

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Caveats from reloption toast_tuple_target
Дата
Msg-id 20190521041803.GC1921@paquier.xyz
обсуждение исходный текст
Ответ на Re: Caveats from reloption toast_tuple_target  (David Rowley <david.rowley@2ndquadrant.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: clean up docs for v12
Следующее
От: Paul A Jungwirth
Дата:
Сообщение: Re: clean up docs for v12