Re: CLUSTER not lose indexes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: CLUSTER not lose indexes
Дата
Msg-id 10821.1025879225@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: CLUSTER not lose indexes  (Alvaro Herrera <alvherre@atentus.com>)
Ответы Re: CLUSTER not lose indexes
Список pgsql-patches
Alvaro Herrera <alvherre@atentus.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



В списке pgsql-patches по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: CLUSTER not lose indexes
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: CLUSTER not lose indexes