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