On Tue, Oct 9, 2012 at 6:11 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> 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. > > Only solution there is to fix SnapshotNow, as we discussed last > Christmas. I'll dig out my patch for that, which IIRC I was nervous of > committing at last minute into 9.2. > Hi Simon, Do you have an URL to this patch? -- Michael Paquier http://michael.otacoo.com