> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> "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.
>
Hmm,your plan seems to need WAL.
We must postpone to build indexes until the end of tuple moving
in vacuum. Once tuple moving started,the consistency between
heap and indexes would be broken. Currently(without WAL) this
inconsistency could never be recovered in case of rollback.
> 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...)
??? Don't pg_class and pg_attribute needs tricky handling either ?
Seems pg_class alone needs to be tricky when we use rel versioning.
Anyway we couldn't rely on indexes of currently vacuuming table.
I don't think it's easy to maintain indexes of pg_class,pg_indexes,
pg_atribute all together properly.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
