Re: unexpected chunk number 2 (expected 0) for toast value ... inpg_toast_18536
От | Andres Freund |
---|---|
Тема | Re: unexpected chunk number 2 (expected 0) for toast value ... inpg_toast_18536 |
Дата | |
Msg-id | 20200316195307.sqksvjjngteh5lyj@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: unexpected chunk number 2 (expected 0) for toast value ... inpg_toast_18536 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: unexpected chunk number 2 (expected 0) for toast value ... in pg_toast_18536
|
Список | pgsql-general |
Hi, On 2020-03-16 12:44:53 -0700, Andres Freund wrote: > On 2020-03-15 20:11:18 -0400, Tom Lane wrote: > > Unfortunately, it seems like you can't do that either, short of > > hacking up the backend or writing some custom C code, because the > > executor won't let you open a toast table as result relation :-(. > > I wonder if we should change it to allow that when > > allow_system_table_mods is true? This isn't the first time we've > > seen people need to be able to do surgery on a toast table. > > I'd be mildly in favor. But it's considerably more than just the > executor check that'd need to change. We don't the right thing for toast > relations in plenty places right now, because we just check for > RELKIND_RELATION - which will break junkvars etc. Hm, and I wonder if there could be problems with HeapTupleSatisfiesToast() too? It doesn't really forsee much DML being done. Greetings, Andres Freund
В списке pgsql-general по дате отправления: