On 2020-02-24 12:21, Kuntal Ghosh wrote:
> I've reproduced the issue on head. And, the patch seems to solve the
> problem. The patch looks good to me. But, I've a small doubt regarding
> the changes in test_decoding regression file.
>
> diff --git a/contrib/test_decoding/sql/toast.sql
> b/contrib/test_decoding/sql/toast.sql
> ..
> -INSERT INTO toasted_several(toasted_key) VALUES(repeat('9876543210', 10000));
> -SELECT pg_column_size(toasted_key) > 2^16 FROM toasted_several;
> +INSERT INTO toasted_several(toasted_key) VALUES(repeat('9876543210', 269));
> +SELECT pg_column_size(toasted_key) > 2^11 FROM toasted_several;
>
> This actually tests whether we can decode "old" tuples bigger than the
> max heap tuple size correctly which is around 8KB. But, the above
> changes will make the tuple size around 3KB. So, it'll not be able to
> test that particular scenario.Thoughts?
OK, this is interesting. The details of this are somewhat unfamiliar to
me, but it appears that due to TOAST_INDEX_HACK in indextuple.c, an
index tuple cannot be larger than 8191 bytes when untoasted (but not
uncompressed).
What the test case above is testing is a situation where the heap tuple
is stored toasted uncompressed (storage external) but the index tuple is
not (probably compressed inline). This is exactly the situation that I
was contending should not be possible, because it cannot be dumped or
restored.
An alternative would be that we make this situation fully supported.
Then we'd probably need at least ALTER INDEX ... ALTER COLUMN ... SET
STORAGE, and some pg_dump support.
Thoughts?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services