Re: Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13)
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, "Imseih (AWS), Sami" <simseih@amazon.com>, Nathan Bossart <nathandbossart@gmail.com>
Date: 2023-01-11T06:40:57Z
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
Commits
-
Avoid using tuple from syscache for update of pg_database.datfrozenxid
- c0ee6943ca1d 12.14 landed
- 72b6098be47e 13.10 landed