JanWieck@t-online.de (Jan Wieck) writes:
> Tom Lane wrote:
>> One answer is to rebuild indexes from scratch during VACUUM,
>> before we vacuum the TOAST relation. We've been talking about
>> doing that for a long time. Maybe it's time to bite the bullet
>> and do it. (Of course that means fixing the relation-versioning
>> problem, which it seems we don't have a consensus on yet...)
> Doesn't matter if we do it before or after, because the main
> heap shouldn't contain any more toast references to deleted
> (later to be vacuumed) toast entries at that time.
No, we must fix the indexes first, so that they contain no bogus
values if we fail while vacuuming the TOAST relation.
> Anyway, it's a nice idea that should solve the problem. For
> indices, which can allways be rebuilt from the heap data, I
> don't see such a big need for the versioning. Only that a
> partially rebuilt index (rebuild crashed in the middle) needs
> another vacuum before the the DB is accessible again. How
> often does that happen?
If it happens just once on one of your system-table indices, you
won't be happy. We've sweated hard to make VACUUM crash-safe,
and I don't want to throw that away because of TOAST.
>> Text *is* marked toastable in current CVS...
> Whow - haven't noticed.
> Will run my tests against text ... parallel. Does it have any
> impact on the regression test execution time? Does any toast
> table (that should now be there in the regression DB) loose
> it's zero size during the tests?
Yes, there are some nonzero-size toast files in there. Haven't
tried to run any timing tests...
regards, tom lane