On 6 October 2012 00:56, Tom Lane <t...@sss.pgh.pa.us> wrote: > 1. These operations think they can use ordinary heap_update operations > to change pg_index entries when they don't have exclusive lock on the > parent table. The lack of ex-lock means that another backend could be > currently loading up its list of index OIDs for the table --- and since > it scans pg_index with SnapshotNow to do that, the heap_update could > result in the other backend failing to see this index *at all*. That's > okay if it causes the other backend to not use the index for scanning... > but not okay if it causes the other backend to fail to make index > entries it is supposed to make. > > I think this could possibly be fixed by using nontransactional > update-in-place when we're trying to change indisvalid and/or > indisready, but I've not really thought through the details. > > 2. DROP INDEX CONCURRENTLY doesn't bother to do > TransferPredicateLocksToHeapRelation until long after it's invalidated > the index. Surely that's no good? Is it even possible to do that > correctly, when we don't have a lock that will prevent new predicate > locks from being taken out meanwhile?
I'm in the middle of reviewing other fixes there, so will comment soon, just not right now. -- Simon Riggs 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
