From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Junfeng Yang <yjerome(at)vmware(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Ashwin Agrawal <aashwin(at)vmware(dot)com> |
Subject: | Re: vac_update_datfrozenxid will raise "wrong tuple length" if pg_database tuple contains toast attribute. |
Date: | 2020-11-30 01:27:09 |
Message-ID: | X8RKbd3rR6iZZZKz@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
pg_database-vacuum-v3.patch | text/x-diff | 2.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2020-11-30 01:43:09 | Re: autovac issue with large number of tables |
Previous Message | Justin Pryzby | 2020-11-30 01:11:46 | Re: should INSERT SELECT use a BulkInsertState? |