| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Subject: | Re: Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13) |
| Date: | 2023-01-11 06:40:57 |
| Message-ID: | Y75Z+RG2+ZvFWgK+@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 10, 2023 at 11:05:04AM -0800, Andres Freund wrote:
> What about a define that forces external toasting very aggressively for
> catalog tables, iff they have a toast table? I suspect doing so for
> non-catalog tables as well would trigger test changes. Running a buildfarm
> animal with that would at least make issues like this much easier to discover.
Hmm. That could work. I guess that you mean to do something like
that in SearchSysCacheCopy() when we build the tuple copy. There is
an access to the where the cacheId, meaning that we know the catalog
involved. Still, we would need a lookup at its pg_class entry to
check after a reltoastrelid, meaning an extra relation opened, which
would be fine under a specific #define, anyway..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2023-01-11 06:49:44 | Re: mprove tab completion for ALTER EXTENSION ADD/DROP |
| Previous Message | Amit Kapila | 2023-01-11 06:39:31 | Re: Fix pg_publication_tables to exclude generated columns |