I wrote:
> * We can not change the toast rel OID of a shared catalog -- there's no
> way to propagate that into the other copies of pg_class. So we need to
> rejigger the logic for heap rewriting a little bit. Toast rel swapping
> has to be handled by swapping their relfilenodes not their OIDs. This
> is no big deal as far as cluster.c itself is concerned, but the tricky
> part is that when we write new toasted values into the new toast rel,
> the TOAST pointers going into the new heap have to be written with the
> original toast-table OID value not the one that the transient target
> toast rel has got. This is doable but it would uglify the TOAST API a
> bit I think.
I've been playing around with different alternatives for solving the
problem of toast-pointer OIDs, but I keep coming back to the above as
being the least invasive and most robust answer. There are two basic
ways that we could do it: pass the OID to use to the toast logic, which
would require adding a parameter to heap_insert and a number of other
places; or add a field to struct Relation that says "when inserting a
TOAST pointer in this relation, use this OID as the toast-table OID
value in the pointer, even if that's different from what the table's OID
appears to be". The latter seems like less of a notational change, so
I'm leaning to that, but wanted to see if anyone prefers the other.
We could avoid this hackery if there were a way for Relation structs to
point at either the old or the new physical relation (relfilenode);
then we'd not need the transient "new heap" relation during CLUSTER/VF,
which would be good for reducing catalog churn. I've concluded that
that's too large a change to undertake for 9.0, but it might be
interesting to try in the future. So I'd prefer that what we do for
now touch as little code as possible so as to be easy to revert; hence
I'm not wanting to change heap_insert's signature.
regards, tom lane