On Fri, Feb 1, 2013 at 6:56 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
