I wrote: > Honza <hon...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers