On Sun, Aug 14, 2011 at 7:43 PM, Greg Stark wrote:
> On Sun, Aug 14, 2011 at 5:15 PM, Tom Lane wrote:
>> There would be some merit in your suggestion if we knew that all/most
>> toasted columns would actually get fetched out of the catcache entry
>> at some point. Then we'd only be moving the co
On Sun, Aug 14, 2011 at 5:15 PM, Tom Lane wrote:
> There would be some merit in your suggestion if we knew that all/most
> toasted columns would actually get fetched out of the catcache entry
> at some point. Then we'd only be moving the cost around, and might even
> save something on repeated ac
I wrote:
> 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
Heikki Linnakangas writes:
> On 14.08.2011 01:13, Tom Lane wrote:
>> 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
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
So I've gotten things fixed to the point where the regression tests seem
to not fall over when contending with concurrent "vacuum full pg_class",
and now expanded the scope of the testing to all the system catalogs.
What's failing for me now is this chunk in opr_sanity:
*** 209,219
NOT
