Re: CLUSTER not lose indexes

Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> I'm looking at pg_class, and relfilenode is equal to oid in all cases
> AFAICS. If I create a new, "random" relfilenode, the equality will not
> hold. Is that OK?

The idea is that OID is the logical table identifier and relfilenode is
the physical identifier (so relfilenode is what should be used in bufmgr
and below). There are undoubtedly a few places that get this wrong, but
we won't be able to ferret them out until someone starts to exercise
the facility.

> Also, is the new relfilenode somehow guaranteed to
> not be assigned to another relation (pg_class tuple, I think)?

I've been wondering about that myself. We might have to add a unique
index on pg_class.relfilenode to ensure this; otherwise, after OID
wraparound there would be no guarantees.

>> In this code, we delete the old relation, then rename the new one. It
>> would be good to have this all happen in one update of
>> pg_class.relfilenode; that way it is an atomic operation.

As long as you have not committed, it's atomic anyway because no one can
see your updates. It'd be nice to do it in one update for efficiency,
but don't contort the code beyond reason to achieve that.

regards, tom lane