Andres Freund <andres@xxxxxxxxxxx> writes: > On 2020-03-16 12:44:53 -0700, Andres Freund wrote: >> On 2020-03-15 20:11:18 -0400, Tom Lane wrote: >>> 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. We've always allowed people to select from toast tables, so if there are planner or executor problems with that, I'd think they'd mostly be bugs that need fixed anyway. Your point about HeapTupleSatisfiesToast is better though. Actually though ... now that I look at the code, I don't understand why tuple deletion would provoke any errors. toast_delete_datum() is not picky about whether it finds consecutive chunk_seq values, or indeed any matching rows at all. So now I think that Karsten's problem traces to writing the query in such a way that something thinks it needs to fetch the pre-update or pre-delete toasted value. Or maybe the query as such is fine, and the problem stems from something like a trigger or logical replication that's trying to fetch the old value? regards, tom lane
