Hi Michael, On 2013-02-07 16:45:57 +0900, Michael Paquier wrote: > Please find attached a patch fixing 3 of the 4 problems reported before > (the patch does not contain docs).
Cool! > 1) Removal of the quadratic dependency with list_append_unique_oid > 2) Minimization of the wait phase for parent relations, this is done in a > single transaction before phase 2 > 3) Authorization of the drop for invalid system indexes I think there's also the issue of some minor changes required to make exclusion constraints work. > The problem remaining is related to toast indexes. In current master code, > tuptoastter.c assumes that the index attached to the toast relation is > unique > This creates a problem when running concurrent reindex on toast indexes, > because after phase 2, there is this problem: > pg_toast_index valid && ready > pg_toast_index_cct valid && !ready > The concurrent toast index went though index_build is set as valid. So at > this instant, the index can be used when inserting new entries. Um, isn't pg_toast_index_cct !valid && ready? > However, when inserting a new entry in the toast index, only the index > registered in reltoastidxid is used for insertion in > tuptoaster.c:toast_save_datum. > toastidx = index_open(toastrel->rd_rel->reltoastidxid, RowExclusiveLock); > This cannot work when there are concurrent toast indexes as in this case > the toast index is thought as unique. > > In order to fix that, it is necessary to extend toast_save_datum to insert > index data to the other concurrent indexes as well, and I am currently > thinking about two possible approaches: > 1) Change reltoastidxid from oid type to oidvector to be able to manage > multiple toast index inserts. The concurrent indexes would be added in this > vector once built and all the indexes in this vector would be used by > tuptoaster.c:toast_save_datum. Not backward compatible but does it matter > for toast relations? I don't see a problem breaking backward compat in that area. > 2) Add new oidvector column in pg_class containing a vector of concurrent > toast index Oids built but not validated. toast_save_datum would scan this > vector and insert entries in index if there are any present in vector. What about 3) Use reltoastidxid if != InvalidOid and manually build the list (using RelationGetIndexList) otherwise? That should keep the additional overhead minimal and should be relatively straightforward to implement? I think your patch accidentially squashed in some other changes (like 5a1cd89f8f), care to repost without? 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
