"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> We can't "drop and recreate" without a solution to the relation
>> versioning issue (unless you are prepared to accept a nonfunctional
>> database after a failure partway through index rebuild on a system
>> table). I think we should do this, but it's not all that simple...
> Is this topic independent of WAL in the first place ?
Sure, unless Vadim sees some clever way of using WAL to eliminate
the need for versioned relations. But as far as I've seen in the
discussions, versioned relations are independent of WAL.
Basically what I want here is to build the new index relation as
a new file (set of files, if large) and then atomically commit it
as the new version of the index.
If we only want to solve the problem of rebuilding indexes, it's
probably not necessary to have true versions, because nothing outside
of pg_index refers to an index. You could build a complete new index
(new OID, new pg_class and pg_attribute entries, the whole nine yards)
as a new set of files, and delete the old index, and your commit of
this transaction would atomically replace the index. (Vacuuming
pg_index's own indexes this way might be a tad tricky though...)
But that approach doesn't solve the problem of making a CLUSTER
operation that really works the way it should. So I'd rather see us
put the effort into doing relation versions.
regards, tom lane