On 2012-12-08 21:24:47 +0900, Michael Paquier wrote: > On Sat, Dec 8, 2012 at 2:19 AM, Andres Freund <and...@2ndquadrant.com>wrote: > > > On 2012-12-07 12:01:52 -0500, Tom Lane wrote: > > > Simon Riggs <si...@2ndquadrant.com> writes: > > > > On 7 December 2012 12:37, Michael Paquier <michael.paqu...@gmail.com> > > wrote: > > > >> - There is still a problem with toast indexes. If the concurrent > > reindex of > > > >> a toast index fails for a reason or another, pg_relation will finish > > with > > > >> invalid toast index entries. I am still wondering about how to clean > > up > > > >> that. Any ideas? > > > > > > > Build another toast index, rather than reindexing the existing one, > > > > then just use the new oid. > > > > Thats easier said than done in the first place. toast_save_datum() > > explicitly opens/modifies the one index it needs and updates it. > > > > > Um, I don't think you can swap in a new toast index OID without taking > > > exclusive lock on the parent table at some point. > > > > The whole swapping issue isn't solved satisfyingly as whole yet :(. > > > > If we just swap the index relfilenodes in the pg_index entries itself, > > we wouldn't need to modify the main table's pg_class at all. > > > I think you are mistaking here, relfilenode is a column of pg_class and not > pg_index. > So whatever the method used for swapping: relfilenode switch or relname > switch, you need to modify the pg_class entry of the old and new indexes.
The point is that with a relname switch the pg_class.oid of the index changes. Which is a bad idea because it will possibly be referred to by pg_depend entries. Relfilenodes - which certainly live in pg_class too, thats not the point - aren't referred to externally though. So if everything else in pg_class/pg_index stays the same a relfilenode switch imo saves you a lot of trouble. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers