On 2012-11-26 16:39:39 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2012-10-31 11:41:37 +0530, Amit Kapila wrote: > >> There seems to be a problem in behavior of Create Index Concurrently and > >> Hot > >> Update in HEAD code . > > > At pgcon.it I had a chance to discuss with Simon how to fix this > > bug. Please check the attached patches - and their commit messages - for > > the fix and some regression tests. > > I looked at this a bit. I am very unhappy with the proposed kluge to > open indexes NoLock in some places. Even if that's safe today, which > I don't believe in the least, any future change in this area could break > it.
I am not happy with it either. But I failed to see a better way. Note that in most of the cases a lock actually is acquired shortly afterwards, just a ->indisvalid or an ->indisready check away. The only exception is RelationGetIndexAttrBitmap which actually needs to look at !indisvalid && !indisready indexes because of HOT. All the former cases could just do a syscache lookup beforehand and skip if it doesn't match their criterion. I wasn't sure about the (performance, notational) overhead of doing a second syscache lookup in those paths. Note that any ->indisvalid/indisready change is protected by waiting for all concurrent backends to finish, so I don't think the separate syscache lookup/index_open would be a problem. For RelationGetIndexAttrBitmap, I don't really see a point in the locks acquired - after all were not protecting the RelationGetIndexList either. Greetings, Andres -- 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
