From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: unexpected chunk number 2 (expected 0) for toast value ... in pg_toast_18536 |
Date: | 2020-03-16 19:53:07 |
Message-ID: | 20200316195307.sqksvjjngteh5lyj@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-03-16 20:22:18 | Re: unexpected chunk number 2 (expected 0) for toast value ... in pg_toast_18536 |
Previous Message | Andres Freund | 2020-03-16 19:44:53 | Re: unexpected chunk number 2 (expected 0) for toast value ... in pg_toast_18536 |