| 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: | Whole Thread | Raw Message | 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? |