On Wed, Nov 25, 2020 at 04:12:15PM +0900, Michael Paquier wrote:
> Yeah, we had better fix and I guess backpatch something here. That's
> annoying.
I have considered that over the weekend, and let's be conservative.
pg_database has gained a toast table since 12, and before that we
would just have an error "row is too big", but nobody has really
complained about that either.
> One thing that strikes me as unwise is that we could run into similar
> problems with vac_update_relstats() in the future, and there have been
> recent talks about having more toast tables like for pg_class. That
> is not worth caring about on stable branches because it is not an
> active problem there, but we could do something better on HEAD.
For now, I have added just a comment at the top of
heap_inplace_update() to warn callers.
Junfeng and Ashwin also mentioned to me off-list that their patch used
a second copy for performance reasons, but I don't see why this could
become an issue as we update each pg_database row only once a job is
done. So I'd like to apply something like the attached on HEAD,
comments are welcome.
--
Michael
