I wrote:
> Honza <honzap@gmail.com> writes:
>> after a months I've found a time to make test-case for this bug, probably:
> Confirmed that this reproduces a problem on HEAD. Will look into it,
> thanks!
I believe I understand what's going on here, and it's not quite as
exciting as it first appears. The issue is that we are failing to
honor the "toasting goes only one level deep" rule in the specific
case of arrays of composite type. So while it's definitely a nasty
bug, it affects only narrow use cases, and doesn't call into question
our whole vacuuming strategy or anything like that.
Specifically, what happens is that the example inserts data values
formed from
array[ROW('description', OLD.description, NEW.description)::changeset]
in which the description fields might be toasted strings. The ROW
expression calls heap_form_tuple, which leaves the descriptions toasted,
which is fine since per coding rule a tuple value can contain toasted
fields. If we'd then inserted the composite value into another tuple
(eg, in preparation for storage), heap_form_tuple would have called
toast_flatten_tuple_attribute() which would have detoasted the nested
tuple's fields and all would be well. But instead, we stuck it into an
array --- and while the array code knows it has to detoast toasted element
values, it does not know about invoking toast_flatten_tuple_attribute on
composite values that might contain nested fields. So we end up with an
array of composite with some embedded toast pointers, and that goes out to
disk in that form. After subsequent updates of the foo table, the
referenced toast entries get deleted, and now we have dangling pointers in
foo_journal.
So basically the array code has got to get taught about calling
toast_flatten_tuple_attribute() when necessary.
regards, tom lane