On 14.08.2011 01:13, Tom Lane wrote:
> On investigation, this turns out to occur when the planner is trying to
> fetch the value of a toasted attribute in a cached pg_statistic tuple,
> and a concurrent "vacuum full pg_statistic" has just finished. The
> problem of course is that vacuum full reassigned all the toast item OIDs
> in pg_statistic, so the one we have our hands on is no longer correct.
>
> In general, *any* access to a potentially toasted attribute value in a
> catcache entry is at risk here. I don't think it's going to be
> feasible, either from a notational or efficiency standpoint, to insist
> that callers always re-lock the source catalog before fetching a
> catcache entry from which we might wish to extract a potentially toasted
> attribute.
>
> I am thinking that the most reasonable solution is instead to fix VACUUM
> FULL/CLUSTER so that they don't change existing toast item OIDs when
> vacuuming a system catalog. They already do some pretty ugly things to
> avoid changing the toast table's OID in this case, and locking down the
> item OIDs too doesn't seem that much harder. (Though I've not actually
> looked at the code yet...)
How about detoasting all datums before caching them? It's surprising
that a datum that is supposedly in a catalog cache, actually needs disk
access to use.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com