Re: Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13)
От | Tom Lane |
---|---|
Тема | Re: Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13) |
Дата | |
Msg-id | 225108.1673337463@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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>) |
Ответы |
Re: Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13)
Re: Avoiding "wrong tuple length" errors at the end of VACUUM on pg_database update (Backpatch of 947789f to v12 and v13) |
Список | pgsql-hackers |
Michael Paquier <michael@paquier.xyz> writes: > Any objections about getting 947789f applied to REL_13_STABLE and > REL_12_STABLE and see this issue completely gone from all the versions > supported? No objections to back-patching the fix, but I wonder if we can find some mechanical way to prevent this sort of error in future. It's surely far from obvious that we need to apply heap_inplace_update to a raw tuple rather than a syscache entry. A partial fix perhaps could be to verify that the supplied tuple is the same length as what we see on-disk? It's partial because it'd only trigger if there had actually been a toasted-field expansion, so it'd most likely not catch such coding errors during developer testing. regards, tom lane
В списке pgsql-hackers по дате отправления: