Re: Composite Datums containing toasted fields are a bad idea(?)

Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-04-27 18:44:16 -0400, Tom Lane wrote:
>> They don't get nearly as upset as they do if the database loses their
>> data.  Yes, in an ideal world, we could fix this and not suffer any
>> performance loss anywhere.  But no such option is on the table, and
>> waiting is not going to make one appear.  What waiting *will* do is
>> afford more opportunities for this bug to eat people's data.

> We make tradeoffs between performance and safety *all the time*.

Really?  I'm not aware of any case where we've left unrecoverable data
corruption go unfixed.  It's true that we've rejected fixing some cases
where plpgsql code might transiently try to use a stale toast pointer ---
but that's a lot different from losing stored data permanently.

> And you *have* come up with an alternative approach.

No, I haven't.  I experimented with a different approach, at Noah's
insistence.  But I did not and will not try to extend it to a complete
solution, first because I'm unsure that a 100% solution can reasonably
be reached that way, and second because that approach *also* entails
performance penalties --- unavoidable ones, unlike this approach where
people can modify their SQL code to avoid fetching unnecessary columns.

If somebody *else* is sufficiently hell-bent on doing it that way that
they will take responsibility for completing and back-patching that
approach, I will stand aside and let them find out the downsides.
Otherwise, I propose to commit and back-patch this version.
        regards, tom lane