Re: Bugs in CREATE/DROP INDEX CONCURRENTLY

On Tue, Oct 9, 2012 at 6:11 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

> On 6 October 2012 00:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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