On 2016-05-10 10:09:07 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Is anybody ready with a good defense for SatisfiesToast not doing any > > actual liveliness checks? > > As long as we do not update toast values after creation, there is no > need; the liveness check on the parent tuple is what's important. > Adding a liveness check on the toast item would merely create new > failure modes with no corresponding benefit.
You mean besides not having a corrupted database like in this case? > Imagine deciding that field 3 of a regular tuple was somehow dead even > though the rest of the tuple is live --- how can that be good? How would ever happen in normal operation? And why are we checking hint bits in HeapTupleSatisfiesToast() in that case? if (!HeapTupleHeaderXminCommitted(tuple)) { if (HeapTupleHeaderXminInvalid(tuple)) return false; The only way I can see the scenario you're described happening is if there's a bug somewhere else. > I concur with Robert that what this looks like is failure to ensure > that toast OIDs are unique, which is an entirely different problem. Well, I did describe how this can come about due to a wraparound, and how GetNewOidWithIndex isn't sufficient to prevent the problem, as it only hints (which are by definition not durable)... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers