On 2016-05-10 10:09:07 -0400, Tom Lane wrote:
> Andres Freund <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
