Search Postgresql Archives

Re: unexpected chunk number 2 (expected 0) for toast value ... in pg_toast_18536

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, 

On March 16, 2020 1:22:18 PM PDT, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>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.

The logic to add/extract junkvars for updated/deleted tables, as well as other parts of the modification code paths, weren't exposed so far though.

I've tried allowing updates/deletes before (at least deletes are needed to e.g handle duplicate values), I'm fairly confident that the junkvar issue is real.

Andres
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux