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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers