On Fri, Feb 1, 2013 at 6:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That is admittedly kind of weird behavior, but I think one could
>> equally blame this on CLUSTER. This is hardly the first time we've
>> had to patch CLUSTER's handling of TOAST tables (cf commits
>> 21b446dd0927f8f2a187d9461a0d3f11db836f77,
>> 7b0d0e9356963d5c3e4d329a917f5fbb82a2ef05,
>> 83b7584944b3a9df064cccac06822093f1a83793) and it doesn't seem unlikely
>> that we might go the full ten rounds.
>
> Yeah, but I'm not sure whether CLUSTER is the appropriate blamee or
> whether it's more like the canary in the coal mine, first to expose
> problematic behaviors elsewhere. The general problem here is really
> that we're cleaning out toast tuples while the referencing main-heap
> tuple still physically exists. How safe do you think that is? That
> did not ever happen before we decoupled autovacuuming of main and toast
> tables, either --- so a good case could be made that that idea is
> fundamentally broken.
I confess I'm not entirely sanguine about that. A similar issue
arises with index tuples referencing heap tuples, and we go to great
lengths to make sure that the last vestiges of the heap tuple can't be
removed until the index tuples are well and truly dead. If we were to
adopt the same approach here, it would mean that, instead of
consulting XIDs at all, we'd remove TOAST pointers only when there
were provably no main-table tuples pointing to them. I'm not really
proposing that, but it's an interesting thought-experiment. What
we're actually doing is relying on values to match exactly that were
never intended as more than an approximation.
Can you point me to the commit that decoupled this? What was the
motivation for it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
